Planification de la capacité de la passerelle Okta Privileged Access
Les ressources que vous allouez à une passerelle dépendent du rôle que joue la passerelle. Une passerelle Okta Privileged Access peut remplir l'un des rôles suivants :
- Proxy d'accès serveur: la passerelle relaie les sessions SSH et RDP vers vos serveurs. Dimensionnez la passerelle en fonction du nombre de sessions simultanées qu'elle doit gérer et du volume d'enregistrements de sessions qu'elle doit stocker.
- Orchestrateur d'infrastructure (Base de données) : la passerelle exécute des tâches de découverte de comptes et de rotation de mots de passe sur vos bases de données intégrées. Dimensionnez la passerelle en fonction du nombre total d'utilisateurs de l'ensemble des bases de données qu'elle dessert.
Les recommandations fournies dans chacune des sections suivantes partent du principe que la passerelle remplit un seul rôle. Okta n'a pas testé de passerelle remplissant ces deux rôles et n'est donc pas en mesure de formuler de recommandation concernant les ressources requises par une telle passerelle.
Planification des capacité du proxy d'accès serveur
Lorsqu'une passerelle relaie des sessions SSH et RDP, le nombre de sessions simultanées détermine les ressources de traitement et de mémoire dont elle a besoin. Si vous activez la capture de session, le volume des enregistrements de session que vous conservez détermine le stockage nécessaire.
Traitement et mémoire
Le type de serveur ou d'instance que vous utilisez pour héberger une passerelle Okta Privileged Access dépend de votre fournisseur.
Une passerelle dotée de deux vCPU et de 4 Go de RAM prend en charge 120 sessions SSH simultanées. L'utilisation du CPU augmente et diminue avec le nombre de sessions, et l'utilisation de la mémoire reste faible.
Dans Amazon Web Services (AWS), une instance de génération actuelle à capacité de pointe de cette taille répond à cette exigence. Par exemple, les instances t3.medium et t4g.medium avec un volume EBS. Les tests d'origine s'exécutaient sur une instance t2.medium, qui correspond à une génération précédente de même taille.
Stockage
Vous devez étudier soigneusement le type et la quantité de stockage dont vous aurez besoin lors du déploiement de la capture de session SSH avec les passerelles Okta Privileged Access.
La solution de stockage idéale est le disque dur (SSD), qui peut être un SSD dédié attaché à la passerelle ou un stockage basé sur un SSD comme les Amazon Elastic Block Stores.
La quantité de stockage dont vous avez besoin dépend de la charge de travail de vos utilisateurs. Par exemple, une session interactive de 30 minutes qui consiste à exécuter une liste de répertoires toutes les 5 secondes est capturée et stockée dans un fichier binaire d'environ 150 Ko.
Si des utilisateurs copient des fichiers avec la commande scp au cours de leur session, les fichiers copiés seront également inclus dans l'enregistrement de la capture de session. Consultez la section Capture de session.
Si l'enregistrement de la session est activé et qu'une passerelle ne dispose pas de l'espace de stockage suffisant pour enregistrer les journaux de session, la passerelle empêchera les connexions pour des raisons de sécurité. Pour éviter ce genre de situation, il est recommandé de surveiller l'utilisation du stockage de vos passerelles pour garantir un espace suffisant pour enregistrer les journaux.
Une méthode permettant de garantir une capacité de stockage suffisante pour les journaux de session consiste à utiliser une destination de stockage dans le cloud. Assurez-vous que le répertoire temporaire où sont stockées les sessions en cours (/tmp sur la plupart des systèmes) dispose de suffisamment d'espace pour stocker les journaux de vos sessions prévues.
Planification des capacités de l'orchestrateur d'infrastructure
Une passerelle d'orchestration effectue la découverte des comptes et la rotation des mots de passe sur vos bases de données intégrées. Le nombre total d'utilisateurs pour cette base de données détermine les ressources de traitement et de mémoire nécessaires.
Additionnez le nombre d'utilisateurs de toutes les bases de données gérées par la passerelle. Le nombre d'intégrations n'est pas le facteur principal ; ainsi, 10 intégrations comptant chacune 100 utilisateurs nécessitent à peu près la même capacité qu'une seule intégration comptant 1 000 utilisateurs.
Comptez tous les utilisateurs que la découverte renvoie, y compris ceux que vous ne gérez pas et ceux qui ne s'authentifient pas à l'aide d'un mot de passe. En les comptant tous, vous restez prudent dans votre estimation.
Recherchez la ligne qui correspond au nombre total d'utilisateurs. Utilisez ces valeurs comme point de départ. Vos exigences peuvent varier en fonction de votre type de base de données, du nombre d'intégrations et de votre charge de travail.
| Nombre total d'utilisateurs dans toutes les bases de données intégrées | Minimum vCPU et RAM | Exemple AWS à capacité de pointe | Exemple AWS à usage général |
|---|---|---|---|
| Jusqu'à 1 500 | 2 vCPU, 4 Go de RAM | t4g.medium | m6a.large |
| De 1 501 à 10 000 | 4 processeurs virtuels, 16 Go de RAM | t4g.xlarge | m6a.xlarge |
| De 10 001 à 50 000 | 8 vCPU, 32 Go de RAM | t4g.2xlarge | m6a.2xlarge |
Considérez les valeurs de vCPU et de RAM comme des exigences, et les noms d'instances comme des exemples qui y répondent. Certains exemples fournissent plus de RAM que le minimum.
Une passerelle d'orchestration utilise peu de ressources CPU entre les cycles de découverte et de rotation, puis les sollicite par courtes rafales pendant l'exécution d'une tâche. Les instances à capacité de pointe correspondent à ce modèle, car elles fonctionnent à un niveau de base faible et puisent dans les crédits accumulés lors d'un pic d'activité.
Au-delà de 1 500 utilisateurs, une instance à usage général constitue le choix par défaut le plus sûr, car la découverte peut faire passer une instance à capacité de pointe à 100 % d'utilisation du CPU pendant quelques secondes. Une instance à capacité de pointe reste une solution adaptée si l'hôte de la passerelle n'exécute aucune autre charge de travail consommant des ressources CPU.
Si vous exécutez la passerelle sur votre propre machine virtuelle ou sur du matériel physique, il n'y a pas de mécanisme de crédit de pointe ; vous devez donc allouer le vCPU et la mémoire vive indiqués dans le tableau en tant que ressources fixes. Les exemples d'usage général montrent la taille équivalente sans capacité de pointe.
Haute disponibilité
Okta recommande deux passerelles dans chaque groupe d'orchestration. Elles garantissent la disponibilité des fonctions de découverte et de rotation si l'une des passerelles venait à faire défaut, et elles se répartissent les tâches.
Dimensionnez les deux passerelles en fonction du nombre total d'utilisateurs du groupe d'orchestration. Ne partagez pas le volume entre elles, car l'une ou l'autre des passerelle doit être capable de supporter la charge totale à elle seule.
Exemples de dimensionnement
Ces exemples montrent comment le nombre total d'utilisateurs, plutôt que le nombre d'intégrations, détermine la recommandation.
| Déploiement | Nombre total d'utilisateurs | Recommandations |
|---|---|---|
| 20 bases de données intégrées avec environ 50 utilisateurs chacune | 1 000 | Deux passerelles, chacune avec deux vCPU et 4 Go de RAM (équivalent à t4g.medium ) |
| Trois bases de données intégrées comptant environ 400 utilisateurs chacune | 1 200 | Deux passerelles, chacune avec deux vCPU et 4 Go de RAM (équivalent à t4g.medium ) |
| Huit bases de données intégrées comptant environ 1 000 utilisateurs chacune | 8 000 | Deux passerelles, chacune avec quatre vCPU et 16 Go de RAM (équivalent à t4g.xlarge) |
Performances de découverte
La découverte est rapide. Sur une passerelle disposant de deux vCPU et de 4 Go de RAM, la découverte s'effectue en moins d'une seconde, quel que soit le nombre d'utilisateurs, jusqu'à 1 500.
| Utilisateurs de la base de données intégrée | Type de découverte |
|---|---|
| 10 | environ 0,5 seconde |
| 100 | environ 0,5 seconde |
| 1 000 | environ 0,7 seconde |
| 1 500 | environ 0,9 seconde |
Les tâches de découverte s'exécutent les unes après les autres, et les exécutions planifiées sont réparties de manière aléatoire entre les intégrations ; ainsi, les intégrations d'un groupe d'orchestration ne lancent pas toutes la découverte au même moment. Une découverte que vous lancez manuellement est une opération ponctuelle. Le partage d'un groupe d'orchestration entre plusieurs intégrations s'avère pratique lorsque le nombre total d'utilisateurs se situe dans la fourchette recommandée.
La découverte effectuée sur une base de données déjà fortement sollicitée peut prendre plus de temps. Cela a une incidence sur le temps de découverte, et non sur la taille de la passerelle dont vous avez besoin.
Performances de rotation
La rotation prend plus de temps que la découverte et utilise moins de CPU. Les rotations s'enchaînent les unes après les autres ; par conséquent, la durée totale d'un lot augmente en fonction du nombre d'utilisateurs concernés par la rotation.
La rotation d'un utilisateur dure environ quatre secondes. Les lots plus importants sont traités à un rythme constant de 2,5 à 5 utilisateurs par seconde. À ce taux, la rotation de 100 utilisateurs prend environ 20 à 40 secondes, et la rotation de 1 000 utilisateurs prend environ 3 à 7 minutes.
La modification du mot de passe se termine en quelques secondes. L'état affiché dans Admin Console ou renvoyé par l'API peut mettre un certain temps à indiquer que la rotation est terminée. Une rotation qui semble être en cours peut déjà être terminée dans la base de données.