DotW: accès restreint à l'API

Est-il possible de restreindre l'accès à l'API? Quelles sont les meilleures pratiques pour empêcher qu'une clé API soit utilisée par un autre hôte pour accéder au pare-feu? Dans la discussion de cette semaine de la semaine, nous examinons de plus près une question membre de la communauté XavierMe interrogé sur l'accès à l'API.

L'API fait partie des fonctionnalités disponibles sur une interface de gestion, et l'accès aux fonctions de gestion peut être contrôlé et limité de plusieurs façons:

Les restrictions les plus simples peuvent être définies en configurant les paramètres de l'interface de gestion et les profils de gestion de l'interface pour ne permettre que certains services tels que ssh et SSL, mais ne permettent pas Telnet ou d'autres services inutiles. L'API est disponible sur l'interface Web uniquement, de sorte que vous pouvez désactiver http/https sur n'importe quelle interface où il n'est pas nécessaire, et utiliser uniquement SSH. Vous pouvez également limiter l'accès aux services de gestion basés sur l'IP source ou le sous-réseau, empêchant les réseaux non autorisés d'accéder entièrement aux services.

Si plusieurs administrateurs différents nécessitent l'accès au pare-feu, mais certains ne sont pas autorisés à accéder à l'API, l'utilisation des rôles Admin vous permet de contrôler davantage les actions disponibles et ce qui est visible ou invisible pour chaque groupe d'administrateurs. Les parties de l'interface graphique peuvent être rendues en lecture seule ou invisibles. Une sortie de journal peut être rendue anonyme, de sorte qu'un administrateur peut être en mesure d'utiliser des journaux pour le dépannage, mais pas l'énumération des utilisateurs:

L'accès à l'API peut également être rendu totalement impossible à un administrateur, ou seulement les pièces nécessaires rendues disponibles. Par exemple, un opérateur est autorisé à collecter des rapports ou à afficher la journalisation, mais pas à effectuer des modifications de configuration ou à exécuter des commandes opérationnelles via l'API. Un script d'ID utilisateur automatisé peut ajouter ou supprimer le mappage utilisateur-IP, mais le compte ne peut pas être utilisé pour accéder à toute autre fonctionnalité d'API:

De la même manière, un administrateur peut également n'avoir aucun accès CLI, accès en lecture seule ou accès limité aux opérations ou aux superutilisateurs:

Enfin, si la case d'option «rôle» est commutée sur le système virtuel, toutes les restrictions mentionnées ci-dessus peuvent être rendues effectives uniquement dans le VSYS assigné alors que les VSYS restantes sont inaccessibles à l'administrateur. Dans le scénario d'un fournisseur de services partagés ou des limites administratives entre les équipes, cela peut permettre aux admins un accès complet au sein de leur propre VSYS sans interférer accidentellement avec un autre client ou de l'équipe de VSYS.

J'espère que vous avez trouvé cette explication utile. N'hésitez pas à suivre la discussion originale ici ou ajouter des commentaires dans la section commentaires ci-dessous

Cordialement

Tom