Pour protéger les ressources ApsaraVideo Live contre toute utilisation non autorisée, utilisez la signature d'URL, les listes de blocage et d'autorisation IP ainsi que l'authentification distante. Ces méthodes renforcent la sécurité et améliorent l'expérience utilisateur de vos flux vidéo en direct.
Présentation
Le contrôle d'accès des domaines d'ingestion est indispensable pour sécuriser vos ressources et empêcher tout accès non autorisé. Il comprend les méthodes suivantes :
Signature d'URL : permet de dépasser les limites de la protection contre le hotlinking basée sur le Referer en vérifiant la légitimité de chaque requête.
Listes de blocage et d'autorisation IP : restreignent ou autorisent l'accès depuis des adresses IP spécifiques, ce qui permet d'identifier et de filtrer les visiteurs.
Authentification distante : transfère les requêtes utilisateur vers un serveur d'authentification désigné pour validation, offrant ainsi une plus grande flexibilité et une sécurité renforcée.
Signature d'URL
Introduction
La signature d'URL fonctionne conjointement avec votre serveur métier pour offrir une méthode sécurisée de protection des ressources de flux en direct. Flux de travail :
Votre serveur métier génère une URL signée contenant les informations d'authentification.
L'utilisateur final utilise cette URL signée pour initier une requête d'ingestion de flux vers ApsaraVideo Live.
Un nœud périphérique d'ApsaraVideo Live décode et valide la signature de l'URL. Si celle-ci est invalide, la requête est rejetée.
Une fois qu'ApsaraVideo Live a authentifié l'URL de la requête, les caractères spéciaux qu'elle contient (tels que = et +) sont échappés.
Pour plus d'informations sur les scénarios applicables, la structure des URL signées et les principes de fonctionnement, consultez la rubrique URL d'ingestion et de streaming signées.
Procédure
Connectez-vous à la console ApsaraVideo Live.
Dans le volet de navigation de gauche, cliquez sur Domain Names. La page Domain Management s'affiche.
Recherchez le domaine d'ingestion à gérer, puis cliquez sur Domain Settings dans la colonne Actions.
Choisissez Streaming Management > Access Control.
-
Cliquez sur l'onglet URL Signing, puis sur Modify.
La section de configuration de l'authentification comprend le bouton bascule URL Signing, le champ Authentication Type (par exemple, Type A), ainsi que les champs Primary Key, Secondary Key et Validity Period (en minutes).
RemarqueLa signature d'URL est activée par défaut lors de l'ajout d'un domaine. Pour la désactiver pour la première fois, vous devez reconnaître le risque d'utilisation non autorisée et signer l'accord de décharge de responsabilité.
Si la signature d'URL est activée, cliquez sur Modify pour mettre à jour les paramètres. Si vous l'avez précédemment désactivée, activez simplement le bouton bascule URL Signing pour la reconfigurer.
-
Configurez les paramètres de signature d'URL et cliquez sur OK.
Paramètre
Description
Authentication Type
Les domaines d'ingestion prennent uniquement en charge la signature de type A.
RemarqueToutes les erreurs de signature d'URL renvoient une erreur 403. Dans ce cas, recalculez la signature.
Pour diagnostiquer la cause exacte de l'échec, vérifiez l'en-tête
X-Tengine-Errordans la réponse HTTP :Erreurs de calcul MD5
Exemple :
X-Tengine-Error:denied by req auth: invalid md5hash=de7bfdc915ced05e17380a149bd760beErreurs d'horodatage
Exemple :
X-Tengine-Error:denied by req auth: expired timestamp=1439469547
Primary Key
Lors de l'ajout d'un domaine, la console génère aléatoirement une clé primaire. Vous pouvez également saisir une clé primaire personnalisée.
Secondary Key
Saisissez un mot de passe de secours pour l'authentification par URL.
RemarqueLes clés primaire et secondaire ont la même validité. La clé secondaire sert principalement à assurer une rotation fluide des clés.
Si vous mettez à jour la clé primaire, toutes les URL signées avec l'ancienne clé primaire deviennent invalides. Pour éviter toute interruption, copiez l'ancienne clé primaire dans le champ de la clé secondaire afin qu'elle continue de fonctionner pendant la transition.
Validity Period
La période de validité définit la durée pendant laquelle l'URL signée reste valide pour initier une ingestion ou une lecture. L'ingestion et la lecture en direct utilisent des connexions persistantes. Une fois démarrées pendant la période de validité, ces sessions se poursuivent même après son expiration. Toutefois, les nouvelles requêtes d'ingestion ou de lecture échouent si l'URL a expiré.
La période de validité par défaut pour un domaine nouvellement ajouté est de 1 jour (1 440 minutes). Vous pouvez personnaliser cette valeur en minutes.
Liste de blocage et liste d'autorisation IP
Introduction
Liste de blocage IP : l'accès au domaine accéléré est refusé aux adresses IP ajoutées à cette liste.
Liste d'autorisation IP : seules les adresses IP ajoutées à cette liste peuvent accéder au domaine accéléré.
-
Les listes de blocage et d'autorisation prennent toutes deux en charge les adresses IPv6 selon les règles de formatage suivantes :
Les lettres hexadécimales de l'adresse IPv6 doivent être en majuscules, par exemple
2001:DB8:0:23:8:800:200C:417A.Les formats IPv6 abrégés utilisant des deux-points doubles (
::) ne sont pas pris en charge, comme2001:0DB8::0008:0800:200C:417A.
Les listes de blocage et d'autorisation prennent également en charge les blocs CIDR. Par exemple,
192.168.0.0/24.
Procédure
Connectez-vous à la console ApsaraVideo Live.
Dans le volet de navigation de gauche, cliquez sur Domain Names. La page Domain Management s'affiche.
Recherchez le domaine d'ingestion à gérer, puis cliquez sur Domain Settings dans la colonne Actions.
Choisissez Streaming Management > Access Control.
Cliquez sur l'onglet IP Blacklist or Whitelist et activez la fonctionnalité.
-
Définissez le List Type et la Rule, puis cliquez sur OK.
Les listes de blocage et d'autorisation sont mutuellement exclusives ; une seule peut être active à la fois. Vous pouvez configurer jusqu'à 1 000 adresses IPv6 ou 3 000 adresses IPv4. Séparez les entrées par des sauts de ligne, sans doublons. La notation CIDR est prise en charge (par exemple,
127.0.0.0/24). Les adresses IPv6 ne sont pas sensibles à la casse et ne prennent pas en charge le format abrégé::.Type
Description
IP Blacklist
L'accès au domaine accéléré est refusé aux adresses IP ajoutées à la liste de blocage.
Whitelist
Seules les adresses IP ajoutées à la liste d'autorisation peuvent accéder au domaine accéléré.
Authentification distante
Introduction
L'authentification distante et la signature d'URL protègent toutes deux les ressources de flux en direct en garantissant que seuls les utilisateurs autorisés peuvent y accéder. Elles diffèrent cependant par leur mise en œuvre :
Signature d'URL : vous fournissez les règles d'authentification au centre de diffusion en direct, qui gère l'ensemble du processus d'authentification.
Authentification distante : vous maintenez votre propre serveur d'authentification. Lorsque le centre de diffusion en direct reçoit une requête utilisateur, il la transfère à votre serveur d'authentification pour validation. Vous êtes responsable de la configuration et de la gestion de ce serveur. L'authentification distante ne prend pas en charge le protocole HTTP Live Streaming (HLS).
Le flux de données pour l'authentification distante est le suivant :
Étape | Description |
① | L'utilisateur envoie une requête d'accès aux ressources contenant des paramètres d'authentification au centre de diffusion en direct. |
② | Le centre de diffusion en direct reçoit la requête et la transfère directement (ou après application de règles spécifiées) au serveur d'authentification. |
③ | Le serveur d'authentification évalue la requête à l'aide des paramètres fournis et renvoie le résultat au centre de diffusion en direct. |
④ | Le centre de diffusion en direct agit en fonction du résultat de l'authentification et renvoie les données à l'utilisateur.
|
Procédure
Connectez-vous à la console ApsaraVideo Live.
Dans le volet de navigation de gauche, cliquez sur Domain Names. La page Domain Management s'affiche.
Recherchez le domaine d'ingestion à gérer, puis cliquez sur Domain Settings dans la colonne Actions.
Choisissez Streaming Management > Access Control.
-
Cliquez sur l'onglet Remote Authentication, activez le bouton bascule, puis configurez les paramètres comme indiqué.
RemarqueUne fois l'authentification distante activée, chaque requête utilisateur est transférée à votre serveur d'authentification. En cas de trafic élevé, assurez-vous que votre serveur peut gérer la charge et offrir des performances adéquates.
Paramètre
Description
Authentication Server Address
Adresse accessible publiquement de votre serveur d'authentification. Le système valide le format et la valeur de l'adresse saisie. Vous pouvez utiliser une URL fixe ou une URL basée sur des variables.
URL fixe : prend en charge HTTP(S). Les valeurs ne doivent pas inclure 127.0.0.1 ou localhost, car elles sont invalides. Exemples :
http(s)://example.aliyundoc.com/auth
http(s)://192.0.2.1/auth
URL basée sur des variables : construisez l'URL d'authentification à l'aide de variables. Pour plus de détails, consultez URL basées sur des variables.
Request Method
Spécifie la méthode de requête HTTP utilisée par le centre de diffusion en direct pour envoyer des requêtes d'authentification à votre serveur d'authentification. Valeurs valides : GET et POST.
Pass Through URL Parameters
Contrôle quels paramètres de l'URL de requête de l'utilisateur sont utilisés pour l'authentification. Choisissez Specified Parameters Passed, Specified Parameters Not Passed ou None.
RemarqueSi vous sélectionnez Specified Parameters Passed ou Specified Parameters Not Passed, saisissez les noms des paramètres dans le champ ci-dessous, séparés par des virgules (,). Exemple :
key1,key2,key3.HTTP Status Code to Return
Code d'état HTTP que votre serveur d'authentification renvoie au centre de diffusion en direct après une authentification réussie. Choisissez l'une des options suivantes :
Successful Authentication : après avoir sélectionné cette option, saisissez un code d'état de succès personnalisé. Le centre de diffusion en direct autorise la requête uniquement si votre serveur renvoie ce code exact. Tous les autres codes entraînent un rejet.
Exemple : définissez le code d'état de succès sur 200. Si votre serveur renvoie 200, l'authentification réussit.
Failed Authentication : après avoir sélectionné cette option, saisissez un code d'état d'échec personnalisé. Le centre de diffusion en direct bloque la requête uniquement si votre serveur renvoie ce code exact. Tous les autres codes entraînent une approbation.
Exemple : définissez le code d'état d'échec sur 403. Si votre serveur renvoie 403, l'authentification échoue.
Authentication Duration (s)
Ce paramètre mesure le temps écoulé entre l'envoi de la requête d'authentification par le centre de diffusion en direct et la réception d'une réponse de votre serveur.
Saisissez un entier compris entre 0 et 30.
Retries on Timeout
Nombre de tentatives effectuées par le centre de diffusion en direct auprès de votre serveur d'authentification après une expiration. Une fois les tentatives épuisées, le centre de diffusion en direct exécute l'action spécifiée sous « Action After Timeout ».
Action After Timeout
Action entreprise par le centre de diffusion en direct lorsque l'authentification expire. Les actions prises en charge sont Allow et Deny :
Allow : en cas d'expiration, le centre de diffusion en direct autorise la requête utilisateur.
Deny : en cas d'expiration, le centre de diffusion en direct rejette la requête et renvoie un code d'état d'échec (par exemple, 403) à l'utilisateur.
Asynchronous Authentication
Lorsque cette option est activée, la lecture démarre sans attendre le résultat de l'authentification distante. Si l'authentification échoue ultérieurement, la lecture s'arrête. Cela évite l'augmentation du délai d'affichage de la première image causée par les délais de l'authentification distante synchrone. Après avoir basculé entre l'authentification synchrone et asynchrone, effectuez des tests pour vous assurer que tout fonctionne comme prévu.
-
Cliquez sur OK pour terminer la configuration.
Après avoir configuré l'authentification distante, vous pouvez la modifier ou la désactiver dans l'onglet Remote Authentication.
Construire une URL avec des variables
Vous pouvez construire l'URL du serveur d'authentification à l'aide de variables, comme décrit ci-dessous :
|
Type |
Description |
|
Variables numériques |
Les variables numériques telles que Par exemple, si l'URL d'ingestion est |
|
Variables alphabétiques |
Les variables alphabétiques telles que Par exemple, si l'URL d'ingestion est |
|
Variables personnalisées |
Les variables personnalisées commencent par le préfixe |
|
Variables NGX |
Toutes les variables Toutes les valeurs référencées sont traitées par la fonction d'échappement d'URL |
|
Variable de nom de flux |
Vous pouvez utiliser |
Si l'URL d'ingestion ou de lecture est rtmp://domain.aliyundoc.com/app/stream?token=***&name=xrc,
et que l'adresse du serveur d'authentification distante est configurée comme suit : http://auth.aliyundoc.com/?app=${udv_host}&streamname=${2}&appname=${1}&token=${arg_token},
alors l'URL d'authentification réelle devient http://auth.aliyundoc.com/?app=domain.aliyundoc.com&streamname=stream&appname=app&token=***.
**Autoriser l'ingestion de flux uniquement depuis un AppName spécifique**
Utilisez la variable numérique ${1} pour transmettre le AppName de l'URL d'ingestion à votre serveur d'authentification, qui vérifie cette valeur par rapport à une liste d'autorisation. Le StreamName n'est pas restreint, de sorte que chaque flux sous un AppName autorisé peut être ingéré, ce qui vous offre une sécurité d'ingestion par application sans avoir à signer chaque flux individuellement. Définissez le paramètre Authentication Server Address sur http://auth.aliyundoc.com/check?AppName=${1}. Si l'URL d'ingestion est rtmp://domain.aliyundoc.com/myapp/stream001?token=***, le centre de diffusion en direct envoie la requête d'authentification à http://auth.aliyundoc.com/check?AppName=myapp. Votre serveur d'authentification vérifie ensuite si myapp figure dans la liste d'autorisation et renvoie le code d'état HTTP que vous avez configuré pour Successful Authentication (par exemple, 200), ce qui permet au centre de diffusion en direct d'accepter l'ingestion du flux, ou le code d'état HTTP que vous avez configuré pour Failed Authentication (par exemple, 403), ce qui amène le centre de diffusion en direct à la rejeter.