Pour apprendre ce qu’est l’autorité adoptée, comment elle fonctionne, et comment la mettre en œuvre.
Ce dossier est issu de notre publication System iNEWS (12/09). Pour consulter les schémas et illustrations associés, rendez-vous dans le club abonnés.
Pendant des années, j’ai participé à diverses discussions techniques sur les mérites et les inconvénients de la sécurisation de la base de données et des fonctions sensibles, au moyen de l’autorité adoptée. On trouve souvent dans ces discussions quelques notions sur la fonction Use Adopted Authority. Ce qui est clair à propos de Adopted Authority et de Use Adopted Authority, est … leur manque de clarté. Alors que la plupart des techniciens comprennent bien ce que fait l’autorité adoptée, c’est l’inverse qui se produit face au concept Use Adopted Authority.
La valeur système Use Adopted Authority (QUSEADPAUT) est vue en général comme un moyen de contrôler quels utilisateurs peuvent créer des programmes qui adoptent l’autorité. Pourtant, ce n’est pas le cas. La valeur système est le moyen de contrôler quels utilisateurs peuvent créer des programmes qui « utilisent l’autorité adoptée » passée à partir d’un programme précédent dans la pile d’appel. C’est un programme précédent dans la pile d’appel qui adopte l’autorité. La valeur système contrôle quels utilisateurs peuvent créer des programmes qui utilisent cette autorité adoptée passée au programme. La valeur système contrôle aussi quels utilisateurs peuvent changer un programme existant pour utiliser l’autorité adoptée passée au programme.
Je pense connaître la principale raison de la confusion : en principe, nous ne limitons pas quels utilisateurs peuvent créer des programmes qui utilisent l’autorité adoptée. Nous créons nos programmes sans nous soucier de savoir s’ils utiliseront l’autorité adoptée. Nous savons qu’ils le feront. Certes, ils n’adopteront pas tous l’autorité, mais ils utiliseront tous n’importe quelle autorité adoptée qui leur aura été passée. Le mot important est « utiliser ». Dans la plupart des sites i, nous comptons sur nos programmes pour utiliser l’autorité adoptée qui leur a été passée. Faute de quoi, nous passerions beaucoup de nuits blanches à traiter des défaillances d’autorité.
Dans cet article, j’examine l’autorité adoptée, son fonctionnement et sa mise en œuvre. J’examine aussi comment utiliser l’attribut de programme USEADPAUT(*NO), lorsque vous ne voulez pas laisser un programme utiliser l’autorité adoptée. Pour plus d’informations sur la valeur système QUSEADPAUT, voir « La valeur système QUSEADPAUT » ci-dessous. A moins d’être prêt à revoir entièrement votre modèle de sécurité applicatif, je vous déconseille de changer la valeur système qu’IBM livre par défaut. En effet, en utilisant la valeur telle qu’elle est livrée, tous les utilisateurs peuvent créer ou changer des programmes pour utiliser l’autorité adoptée.
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
