Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 2. Aperçu Sécurité

2.1. Sécurité déclarative
Copier lien

Sécurité déclarative est une méthode de séparation des problèmes de sécurité du code d'application, en utilisant le conteneur pour gérer la sécurité. Le conteneur procure un système d'autorisation basé soit sur les permissions de fichiers ou basé utilisateur, groupe ou rôle. Cette approche est normalement supérieure à la sécurité programmatique, qui donne à l'application toutes les responsabilités pour la sécurité.
La plate-forme JBoss EAP 6 fournit une sécurité déclarative par les domaines de sécurité.
Report a bug

2.1.1. Java EE Declarative Security
Copier lien

Le modèle de sécurité J2EE est déclaratif en ce sens que vous décrivez les rôles de sécurité et les autorisations dans un descripteur XML standard plutôt que d'encastrer la sécurité dans votre composant d'entreprise. Cela isole la sécurité à partir du code niveau entreprise parce que la sécurité a tendance à être davantage une fonction d'où le composant est déployé plutôt que liée à un aspect inhérent de la logique métier du composant. Par exemple, considérez un guichet automatique bancaire (GAB) devant être utilisé pour accéder à un compte de banque. Les exigences de sécurité, les rôles et les autorisations peuvent varier indépendamment de la façon dont vous accédez au compte de banque, suivant la Banque qui gère le compte, où se trouve l'ATM, et ainsi de suite.
La sécurisation d'une application J2EE repose sur la spécification des besoins de sécurité de l'application via les descripteurs de déploiement J2EE standards. Vous sécuriser l'accès aux EJBs et aux composants web d'une application d'entreprise en utilisant les descripteurs de déploiement ejb-jar.xml et web.xml.
Report a bug

2.1.2. Références de sécurité
Copier lien

Les EJB (Enterprise Java Beans) et les servlets peuvent déclarer un ou plusieurs éléments <security-role-ref>.
Illustration du Modèle de référence des rôles de sécurité
View larger image
Illustration du Modèle de référence des rôles de sécurité

Figure 2.1. Modèle de référence de rôles de sécurité

Cet élément déclare que le composant utilise la valeur de l'attribut role-nameType de l'élément <role-name> comme argument de la méthode isCallerInRole(String). En utilisant la méthode isCallerInRole, un composant est en mesure de vérifier si l'invocateur est dans un rôle qui a été déclaré avec un élément <security-role-ref> ou <role-name>. La valeur de l'élément <role-name> doit être reliée à un élément <security-role> par l'élément <role-link>. L'utilisation typique de isCallerInRole est pas être défini en utilisant les éléments <method-permissions> basé-rôle.

Exemple 2.1. fragment de descripteur ejb-jar.xml

  
  <!-- A sample ejb-jar.xml fragment -->
    <ejb-jar>
      <enterprise-beans>
        <session>
          <ejb-name>ASessionBean</ejb-name>
          ...
          <security-role-ref>
            <role-name>TheRoleICheck<role-name>
              <role-link>TheApplicationRole</role-link>
          </security-role-ref>
        </session>
      </enterprise-beans>
    ...
    </ejb-jar>
Copy to Clipboard Toggle word wrap

Note

Il s'agit d'un exemple uniquement. Dans les déploiements, les éléments de cette section doivent contenir les noms de rôle pertinents au déploiement EJB.

Exemple 2.2. fragment de descripteur web.xml

<web-app>
  <servlet>
    <servlet-name>AServlet</servlet-name>
    ...
    <security-role-ref>
      <role-name>TheServletRole</role-name>
      <role-link>TheApplicationRole</role-link>
    </security-role-ref>
  </servlet>
    ...
</web-app>
Copy to Clipboard Toggle word wrap
Report a bug

2.1.3. Identité Sécurité
Copier lien

Un EJB (Enterprise Java Bean) peut spécifier l'identité qu'un autre EJB doit utiliser lorsqu'il appelle des méthodes sur les composants à l'aide de l'élément <security-identity>.
Illustration de ce modèle
View larger image
Illustration de ce modèle

Figure 2.2. Modèle J2EE Security Identity Data Model

L'identité de l'invocation peut être celle de l'appelant en cours, ou il peut correspondre un rôle spécifique. L'assembleur d'applications utilise l'élément <security-identity> avec un élément enfant de <use-caller-identity>. Cela indique que l'identité de l'appelant en cours doit être propagée comme l'identité de sécurité pour les appels de méthode de l'EJB. La propagation d'identité de l'appelant est la valeur par défaut utilisée en l'absence d'une déclaration d'élément <security-identity> explicite.
Sinon, l'assembleur d'application peut utiliser l'élément enfant <run-as> ou <role-name> pour spécifier qu'un rôle de sécurité spécifique fourni par la valeur de l'élément <role-name> doit servir d'identité de sécurité pour les appels de méthode de l'EJB.
Notez que cela ne change pas l'identité de l'appelant telle qu'elle est perçue par la méthode EJBContext.getCallerPrincipal(). À la place, les rôles de sécurité de l'appelant sont définis par l'élément <run-as> ou <role-name>.
Un cas d'utilisation de l'élément <run-as> consiste à empêcher les clients externes d'accéder aux beans EJB internes. Vous pouvez configurer ce comportement en affectant des éléments EJB internes <method-permission> qui limitent l'accès à un rôle jamais attribué à un client externe. Les EJB qui doivent à leur tour utiliser les EJB internes qui sont ensuite configurés avec un <run-as> ou un <role-name> qui correspond au rôle restreint. Le fragment suivant de descripteur décrit un exemple d'utilisation de l'élément <security-identity>. 
<ejb-jar>
    <enterprise-beans>
        <session>
            <ejb-name>ASessionBean</ejb-name>
            <!-- ... -->
            <security-identity>
                <use-caller-identity/>
            </security-identity>
        </session>
        <session>
            <ejb-name>RunAsBean</ejb-name>
            <!-- ... -->
            <security-identity>
                <run-as>
                    <description>A private internal role</description>
                    <role-name>InternalRole</role-name>
                </run-as>
            </security-identity>
        </session>
    </enterprise-beans>
    <!-- ... -->
</ejb-jar>
Copy to Clipboard Toggle word wrap
Lorsque vous utilisez un <run-as> pour attribuer un rôle spécifique aux appels sortants, un principal nommé anonymous est attribué à tous les appels sortants. Si vous voulez un autre principal à associer à l'appel, vous devez associer un <run-as-principal> au bean du fichier jboss.xml. Le fragment suivant associe un principal nommé internal avec RunAsBean de l'exemple précédent. 
<session>
    <ejb-name>RunAsBean</ejb-name>
    <security-identity>
        <run-as-principal>internal</run-as-principal>
    </security-identity>
</session>
Copy to Clipboard Toggle word wrap
L'élément <run-as> est également disponible dans les définitions du servlet du fichier web.xml. L'exemple suivant montre comment assigner le rôle InternalRole à un servlet : 
  <servlet>
    <servlet-name>AServlet</servlet-name>
    <!-- ... -->
    <run-as> 
        <role-name>InternalRole</role-name>
    </run-as>
  </servlet>
Copy to Clipboard Toggle word wrap
Les appels de ce servlet sont associés au principal «anonymous». L'élément <run-as-principal> se trouve dans le fichier jboss-web.xml pour assigner un principal spécifique qui puisse correspondre à un rôle run-as. Le fragment suivant montre comment associer un principal nommé internal au serveur ci-dessus. 
  <servlet>
    <servlet-name>AServlet</servlet-name>
    <run-as-principal>internal</run-as-principal>
  </servlet>
Copy to Clipboard Toggle word wrap
Report a bug

2.1.4. Rôles de sécurité
Copier lien

Le nom de rôle de sécurité référencé soit par l'élément security-role-ref ou élément de security-identity doit mapper à un des rôles déclarés de l'application. Un assembleur d'applications définit les rôles de sécurité logique en déclarant les éléments security-role. La valeur de role-name est un nom de rôle d'application logique comme Administrateur, Architecte, ResponsableVentes, etc.
Les spécifications J2EE précisent qu'il est important de garder à l'esprit que les rôles de sécurité du descripteur de déploiement soient utilisés pour définir l'aperçu de la sécurité logique d'une application. Les rôles définis dans les descripteurs de déploiement J2EE ne doivent pas être confondus avec les groupes d'utilisateurs, les utilisateurs, les principaux et d'autres concepts qui existent dans l'environnement opérationnel de l'entreprise cible. Les rôles de descripteur de déploiement sont des constructions d'applications avec des noms de domaine d'application spécifiques. Par exemple, une application bancaire pourrait utiliser des noms de rôles tels que DirecteurBank, Guichetier ou Client.
Dans JBoss EAP, un élément de security-role est seulement utilisé pour mapper les valeurs de security-role-ref/role-name au rôle logique qui fait référence au rôle du composant. Les rôles assignés de l'utilisateur représentent une fonction dynamique du gestionnaire de sécurité de l'application. JBoss n'a as besoin de la définition des éléments de security-role pour déclarer des permissions de méthode. Toutefois, la spécification d'éléments de security-role est toujours une pratique conseillée pour assurer la portabilité entre les serveurs d'applications et la maintenance du descripteur de déploiement.

Exemple 2.3. Un fragment de descripteur ejb-jar.xml qui illustre l'utilisation de l'élément security-role.

<!-- A sample ejb-jar.xml fragment --><ejb-jar><assembly-descriptor><security-role><description>The single application role</description><role-name>TheApplicationRole</role-name></security-role></assembly-descriptor></ejb-jar>
Copy to Clipboard Toggle word wrap

Exemple 2.4. Un exemple web.xml qui illustre l'utilisation de l'élément security-role.

<!-- A sample web.xml fragment --><web-app><security-role><description>The single application role</description><role-name>TheApplicationRole</role-name></security-role></web-app>
Copy to Clipboard Toggle word wrap
Report a bug

2.1.5. Permissions de méthodes EJB
Copier lien

Un assembleur d'applications peut définir les rôles autorisés à appeler les méthodes d'interfaces d'accueil ou éloignées de l'EJB par le biais de déclarations d'élément method-permission.
Illustration d'élément de permissions de méthode J2EE
View larger image
Illustration d'élément de permissions de méthode J2EE

Figure 2.3. Élément de Permission de méthode J2EE

Chaque élément de method-permission contient un ou plusieurs éléments enfants role-name qui définissent les rôles logiques autorisés à accéder aux méthodes EJB identifiées par les éléments enfants de la méthode. Vous pouvez également spécifier un élément unchecked à la place de l'élément role-name pour déclarer que tout utilisateur authentifié peut accéder aux méthodes identifiées par les éléments enfants de méthode. De plus, vous pouvez déclarer que personne ne devrait avoir accès à une méthode qui comporte l'élément de la exclude-list (liste d'exclusion). Si un EJB a des méthodes qui n'ont pas été déclarées comme accessibles par un rôle à l'aide d'un élément de method-permission, la valeur par défaut des méthodes EJB sera exclusion d'utilisation. Cela revient à rendre les méthodes par défaut à exclude-list.
Illustration d'élément de méthode J2EE
View larger image
Illustration d'élément de méthode J2EE

Figure 2.4. Élément de méthode J2EE

Il existe trois styles de déclarations d'éléments de méthodes pris en charge.
Le premier est utilisé pour se référer à toutes les méthodes d'interface de composant et d'accueil du bean d'entreprise nommé : 
<method><ejb-name>EJBNAME</ejb-name><method-name>*</method-name></method>
Copy to Clipboard Toggle word wrap
Le second style est utilisé pour faire référence à une méthode particulière de l'interface de composant ou d'accueil du bean enterprise nommé : 
  <method><ejb-name>EJBNAME</ejb-name><method-name>METHOD</method-name></method>
Copy to Clipboard Toggle word wrap
S'il y a plusieurs méthodes possédant le même nom surchargé, ce style se réfèrera à toutes les méthodes de surchargement.
Le troisième style se réfère à une méthode particulière qui fait partie d'un ensemble de méthodes ayant un nom surchargé : 
<method><ejb-name>EJBNAME</ejb-name><method-name>METHOD</method-name><method-params><method-param>PARAMETER_1</method-param><!-- ... --><method-param>PARAMETER_N</method-param></method-params></method>
Copy to Clipboard Toggle word wrap
La méthode doit être définie dans l'interface de domicile ou à distance du bean entreprise spécifié. Les valeurs d'élément method-param correspondent au nom qualifié complet du type de paramètre de méthode correspondante. S'il y a plusieurs méthodes avec la même signature surchargée, la permission s'appliquera à l'ensemble des méthodes surchargées correspondantes.
L'élément optionnel method-intf peut être utilisé pour différencier des méthodes qui ont le même nom ou signature définis à la fois dans les interfaces d'accueil ou éloignées d'un bean enterprise.
Exemple 2.5, « Un fragment de descripteur ejb-jar.xml qui illustre l'utilisation de l'élément method-permission. » donne des exemples complets d'utilisation d'élément method-permission.

Exemple 2.5. Un fragment de descripteur ejb-jar.xml qui illustre l'utilisation de l'élément method-permission.

<ejb-jar><assembly-descriptor><method-permission><description>The employee and temp-employee roles may access any
                method of the EmployeeService bean </description><role-name>employee</role-name><role-name>temp-employee</role-name><method><ejb-name>EmployeeService</ejb-name><method-name>*</method-name></method></method-permission><method-permission><description>The employee role may access the findByPrimaryKey,
                getEmployeeInfo, and the updateEmployeeInfo(String) method of
                the AardvarkPayroll bean </description><role-name>employee</role-name><method><ejb-name>AardvarkPayroll</ejb-name><method-name>findByPrimaryKey</method-name></method><method><ejb-name>AardvarkPayroll</ejb-name><method-name>getEmployeeInfo</method-name></method><method><ejb-name>AardvarkPayroll</ejb-name><method-name>updateEmployeeInfo</method-name><method-params><method-param>java.lang.String</method-param></method-params></method></method-permission><method-permission><description>The admin role may access any method of the
                EmployeeServiceAdmin bean </description><role-name>admin</role-name><method><ejb-name>EmployeeServiceAdmin</ejb-name><method-name>*</method-name></method></method-permission><method-permission><description>Any authenticated user may access any method of the
                EmployeeServiceHelp bean</description><unchecked/><method><ejb-name>EmployeeServiceHelp</ejb-name><method-name>*</method-name></method></method-permission><exclude-list><description>No fireTheCTO methods of the EmployeeFiring bean may be
                used in this deployment</description><method><ejb-name>EmployeeFiring</ejb-name><method-name>fireTheCTO</method-name></method></exclude-list></assembly-descriptor></ejb-jar>
Copy to Clipboard Toggle word wrap
Report a bug

2.1.6. Annotations de sécurité de Beans Enterprise
Copier lien

Les Beans Enterprise utilisent des annotations pour transmettre des informations au programme de déploiement sur la sécurité et autres aspects de l'application. Le déployeur peut mettre en place la stratégie de sécurité de bean enterprise qui convient à l'application, si spécifié dans les annotations, ou le descripteur de déploiement.
Toute valeur de méthode spécifiée explicitement dans le descripteur de déploiement substituent les valeurs de l'annotation. Si une valeur de méthode n'est pas spécifiée dans le descripteur de déploiement, ces valeurs assorties d'annotations seront utilisées. La granularité dominante est sur une base méthode.
Voici quelques annotations de sécurité qui peuvent être utilisées dans un Bean Enterprise :
@DeclareRoles
Déclare chaque rôle de sécurité déclaré dans le code. Pour plus d'informations sur la configuration des rôles, voir Java EE 5 Tutorial Declaring Security Roles Using Annotations.
@RolesAllowed, @PermitAll, and @DenyAll
Indique les permissions de méthodes pour les annotations. Pour plus d'informations sur la configuration des permissions de méthodes d'annotations, voir Java EE 5 Tutorial Specifying Method Permissions Using Annotations.
@RunAs
Configure l'identité de sécurité propagée d'un composant. Pour plus d'informations sur la façon de configurer les identités de sécurité propagées par des annotations, voir Java EE 5 Tutorial Configuring a Component’s Propagated Security Identity.
Report a bug

2.1.7. Contraintes de sécurité de contenu web
Copier lien

Dans une application web, la sécurité se définit par les rôles qui ont accès au contenu par un modèle d'url qui identifie le contenu protégé. Ce groupe d'informations est déclaré par l'élément web.xml security-constraint.
Illustration des contraintes de sécurité de contenu web
View larger image
Illustration des contraintes de sécurité de contenu web

Figure 2.5. Contraintes de sécurité de contenu web

La contenu à sécuriser est déclarée à l'aide d'un ou plusieurs éléments <web-resource-collection>. Chaque élément <web-resource-collection> contient une série facultative d'éléments <url-pattern> suivie d'une série facultative d'éléments <http-method>. La valeur de l'élément <url-pattern > spécifie une URL qui doit correspondre à une URL de requête pour que la demande corresponde à une tentative d'accès au contenu sécurisé. La valeur de l'élément <http-method> spécifie un type de requête HTTP à autoriser.
L'élément optionnel <user-data-constraint> spécifie les exigences de la couche de transport du client pour la connexion au serveur. L'exigence peut être pour l'intégrité du contenu (empêchant la falsification dans le processus de communication de données) ou de la confidentialité (empêchant la lecture en transit). L'élément <transport-guarantee> indique le degré de protection de la communication entre le client et le serveur. Ses valeurs sont NONE, INTEGRAL, et CONFIDENTIAL. Une valeur NONE signifie que l'application n'a pas besoin de garantie de transport. Une valeur INTEGRAL signifie que l'application requiert que les données envoyées entre le client et le serveur soient envoyées de telle sorte qu'elles ne puissent pas être modifiées en transit. Une valeur CONFIDENTIAL signifie que l'application requiert que les données soient transmises d'une manière qui empêche les autres entités d'observer le contenu de la transmission. Dans la plupart des cas, la présence de INTEGRAL ou CONFIDENTIAL indique qu'il faut utiliser SSL.
L'élément optionnel <login-config> est utilisé pour configurer la méthode d'authentification qui doit être utilisée, le nom de domaine qui doit être utilisé pour l'application et les attributs qui sont nécessaires pour le mécanisme de connexion du formulaire.
Illustration de Configuration de connexion web
View larger image
Illustration de Configuration de connexion web

Figure 2.6. Configuration de connexion web

L'élément enfant <auth-method> spécifie le mécanisme d'authentification de l'application web. Comme condition préalable, l'accès à toutes les ressources web qui sont protégées par une contrainte de permission, un utilisateur doit avoir authentifié par le biais du mécanisme configuré. Les valeurs <auth-method> légales sont BASIC, DIGEST, FORM, et CLIENT-CERT. L'élément enfant <realm-name> spécifie le nom de domaine à utiliser en HTTP de base et l'autorisation digest. L'élément enfant <form-login-config> spécifie le log in et les pages d'erreur devant être utilisées pour le log in basé-formulaire. Si la valeur <auth-method> n'est pas FORM, alors form-login-config et ses éléments enfants seront ignorés.
L'exemple de configuration suivant indique que n'importe quel URL se trouvant sous le chemin d'accès /restriction de l'application web requiert un rôle AuthorizedUser. Il n'y a aucune garantie de transport nécessaire et la méthode d'authentification utilisée pour obtenir l'identité de l'utilisateur est l'authentification HTTP BASIC.

Exemple 2.6. Fragment de descripteur web.xml

<web-app>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Secure Content</web-resource-name>
            <url-pattern>/restricted/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>AuthorizedUser</role-name>
        </auth-constraint>
        <user-data-constraint>
            <transport-guarantee>NONE</transport-guarantee>
        </user-data-constraint>
    </security-constraint>
    <!-- ... -->
    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>The Restricted Zone</realm-name>
    </login-config>
    <!-- ... -->
    <security-role>
        <description>The role required to access restricted content </description>
        <role-name>AuthorizedUser</role-name>
    </security-role>
</web-app>
Copy to Clipboard Toggle word wrap
Report a bug

2.1.8. Activer l'authentification basée formulaire
Copier lien

L'authentification basée formulaire offre la flexibilité de définir une page JSP/HTML personnalisée de connexion, et une page séparée sur laquelle les utilisateurs sont redirigés si une erreur a lieu lors de la connexion.
L'authentification basée formulaire est définie en incluant <auth-method>FORM</auth-method> dans l'élément <login-config> du descripteur de déploiement, web.xml. La connexion et les pages d'erreur sont également définies dans <login-config>, comme suit : 
<login-config>
  <auth-method>FORM</auth-method>
  <form-login-config>
    <form-login-page>/login.html</form-login-page>
    <form-error-page>/error.html</form-error-page>
  </form-login-config>
</login-config>
Copy to Clipboard Toggle word wrap
Lorsqu'une application web avec l'authentification par formulaire est déployée, le conteneur web utilise FormAuthenticator pour diriger les utilisateurs vers la page appropriée. JBoss EAP gère un pool de session afin que les informations d'authentification n'aient pas besoin d'être présentes pour chaque demande. Lorsque FormAuthenticator reçoit une demande, il interroge org.apache.catalina.session.Manager pour savoir s'il y a une session existante. Si aucune session n'existe, une nouvelle session sera créée. FormAuthenticator vérifie alors les informations d'identification de la session.

Note

Chaque session est identifiée par un ID de session, une chaîne de 16 octets générée à partir de valeurs aléatoires. Ces valeurs sont extraites de /dev/urandom (Linux) par défaut et hachées avec MD5. Les vérifications sont effectuées lors de la création de l'ID de session pour s'assurer que l'ID créé soit unique.
Une fois vérifiée, l'ID de session est attribué dans le cadre d'un cookie et ensuite renvoyé au client. Ce cookie revient dans les requêtes clientes suivantes et sera utilisé pour identifier la session utilisateur.
Le cookie passée au client est une paire nom-valeur avec plusieurs attributs facultatifs. L'attribut d'identifiant est appelé JSESSIONID. Sa valeur est une chaîne hexadécimale de l'ID de session. Ce cookie est configuré pour être non persistant. Cela signifie que du côté client, il sera supprimé lorsque le navigateur se fermera. Côté serveur, les sessions expirent après 60 secondes d'inactivité, quand les objets session et leurs informations d'identification seront supprimés.
Si un utilisateur tente d'accéder à une application web protégée par l'authentification formulaire, FormAuthenticator met en cache la demande, crée une nouvelle session si nécessaire et redirige l'utilisateur vers la page de connexion définie dans login-config. (Dans l'exemple de code précédent, la page de connexion est login.html.) L'utilisateur entre alors son nom d'utilisateur et son mot de passe dans le formulaire HTML fourni. Les nom d'utilisateur et mot de passe sont passés à FormAuthenticator par l'intermédiaire de l'action de formulaire j_security_check.
Le FormAuthenticator authentifie alors le nom d'utilisateur et le mot de passe par rapport au domaine attaché au contexte de l'application web. Dans JBoss Enterprise Application Platform, le domaine est JBossWebRealm. Lorsque l'authentification réussit, FormAuthenticator récupère la requête enregistrée à partir du cache et redirige l'utilisateur vers sa requête initiale.

Note

Le serveur reconnaît les requêtes d'authentification de formulaire que lorsque les URI se terminent par /j_security_check et que les paramètres j_username et j_password existent.
Report a bug

2.1.9. Activation de la Sécurité déclarative
Copier lien

Les éléments de sécurité Java EE dont on a parlé jusqu'à présent décrivent les exigences de sécurité uniquement du point de vue de l'application. Comme les éléments de sécurité Java EE déclarent des rôles logiques, le déployeur d'applications mappe les rôles du domaine d'application dans l'environnement de déploiement. Les spécifications Java EE omettent ces détails spécifiques au serveur de l'application.
Pour mapper les rôles d'application dans l'environnement de déploiement, vous devez spécifier un gestionnaire de sécurité qui implémente le modèle de sécurité de Java EE à l'aide de descripteurs de déploiement JBoss EAP. Reportez-vous à l'exemple de module de connexion personnalisé pour plus de détails de cette configuration de sécurité.
Report a bug
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début