Comprendre le démarrage d’une session CAS

CAS... un sujet que j'aborde inlassablement dans mes articles. Cependant, cela n'est pas en vain, car c'est pour une noble cause. CAS est un domaine si riche et vaste que, après avoir lu cet article (et tous ceux qui traitent de ce sujet sur mon blog), vous serez reconnaissant de partager avec vous toutes ces informations précieuses.

Avec SAS Viya, il existe plusieurs façons de se connecter au moteur d'analyse SAS Cloud Analytic Services (CAS), également appelé serveur CAS. Les sessions CAS résultantes peuvent s'exécuter sous le compte de service de l'instance CAS ou sous l'identité de l'utilisateur final.

Cette situation est encore plus complexe en fonction de l'utilisation du protocole d'authentification Kerberos par le client CAS, ce qui entraîne des différences en fonction de l'exécution de CAS sous Linux ou Windows.

Les différentes applications SAS Viya ont des méthodes de connexion par défaut, ce qui influence le propriétaire du processus de leur session CAS et, en fin de compte, le contexte de sécurité physique qui en découle.

Comprendre le comportement par défaut de la session CAS pour chaque application et comment ces paramètres par défaut peuvent être contournés et adaptés pour prendre en charge la politique d'accès aux données est au cœur de cet article.

SOMMAIRE

INTRODUCTION

IDENTITÉ ET CONTEXTES DE SÉCURITÉ

DÉTERMINER LES CONTEXTES DE SÉCURITÉ DES SESSIONS CAS

MÉTHODES D'AUTHENTIFICATION DE CAS

FLUX DE DÉCISION POUR LE LANCEMENT DES SESSIONS CAS

QUELQUES MESSAGES ET ERREURS

GROS PLAN SUR LES BINAIRES SAS

CONCLUSION

POUR ALLER PLUS LOIN

INTRODUCTION

SAS Viya comprend plusieurs moteurs d'exécution qui offrent la capacité d'effectuer un traitement informatique précieux. L'environnement d'exécution de la programmation SAS traditionnelle (SPRE) continue d'exister dans SAS Viya aux côtés du moteur d'analyse en mémoire SAS Cloud Analytic Services (CAS) et du Service Micro Analytique SAS (MAS). Lorsque ces moteurs d'exécution accèdent à des sources de données sensibles, leurs sessions doivent être instanciées de manière à garantir un accès aux données conforme à vos politiques de sécurité.

CAS est le moteur principal pour effectuer des analyses et des scores en mode batch sur de grandes tables en mémoire vive (RAM) à la vitesse de la mémoire à accès aléatoire. Les sessions CAS sont capables d'accéder à des sources de données externes provenant de différents fournisseurs de données et de charger ces données en mémoire pour créer des tables CAS destinées à l'analyse. La plupart des applications web clientes se connectent directement à CAS, cependant, certains clients SAS Viya utilisent des sessions de calcul SPRE comme intermédiaires vers CAS. Ces sessions de calcul sont également en mesure d'accéder à des données sensibles. Des clients open-source peuvent également se connecter à CAS.

Cet article se concentre principalement sur les données accessibles via le moteur CAS et sur la manière dont ses sessions sont initiées. ( Si le lancement des services Compute vous intéresse, c'est par la : Gros plan sur le Compute Server et le Compute Service dans SAS Viya et SAS Compute Server et Compute Service

Les variations dans le lancement des sessions, qui dépendent de la méthode d'authentification CAS, ont un impact sur l'identité des sessions et leur contexte de sécurité. Pour être en conformité avec les exigences d'un modèle d'autorisation sécurisé, il est essentiel de mettre en place correctement le lancement des sessions CAS, en accord avec les fournisseurs d'authentification en place pour SAS Viya et les fournisseurs de données pertinents. Dans les scénarios où les sessions de calcul SPRE sont utilisées comme moyen d'accès aux données, il est également nécessaire de tenir compte de la manière dont ces sessions de calcul sont initiées, ce qui affecte leur identité et leur contexte de sécurité.

IDENTITÉ ET CONTEXTES DE SÉCURITÉ

Les privilèges d'accès aux données sont pertinents uniquement dans le contexte d'une identité particulière.

Lorsque vous vous connectez à n'importe quelle application web SAS Viya, vous établissez votre identité SAS Viya. Si votre navigateur n'a pas encore établi de session avec le service SASLogon, vous êtes redirigé vers SASLogon pour une authentification initiale.

Le service SASLogon est une implémentation d'un serveur d'autorisation OAuth 2.0 qui prend en charge les extensions Open ID Connect pour l'authentification.

Lorsqu'un utilisateur est authentifié, SASLogon crée un jeton d'accès OAuth (avec l'aide du service des identités) contenant votre nom d'utilisateur et toutes vos affiliations de groupe pour établir un profil d'identité.

Le jeton d'accès OAuth représente le contexte de sécurité de l'application de votre identité SAS Viya. Les applications web visuelles SAS Viya utilisent le jeton d'accès pour déterminer à quelles ressources SAS Viya (rapports et dossiers de contenu) vous avez accès en tant qu'utilisateur privilégié.

Les sessions CAS utilisent le jeton d'accès pour déterminer à quelles caslibs et tables chargées vous avez accès.

Les sessions SPRE peuvent également connecter les bibliothèques SAS traditionnelles aux caslibs auxquelles votre identité SAS Viya a accès.

DÉTERMINER LES CONTEXTES DE SÉCURITÉ DES SESSIONS CAS

Le facteur principal pour déterminer le propriétaire des processus de la session CAS est la méthode d'authentification utilisée pour se connecter à CAS.

Le serveur CAS prend en charge différents types d'informations d'identification pour l'authentification, qui influencent la manière dont la session CAS de l'utilisateur est lancée, et finalement le contexte de sécurité du fournisseur de données. CAS prend en charge les types d'authentification suivants.

• Authentification SAS Viya OAuth

• Authentification externe (hôte)

• Authentification Kerberos

Pour contrôler efficacement le contexte de sécurité de la session CAS et garantir le niveau approprié d'accès aux données pour chaque utilisateur, il est essentiel de bien connaître chacune des méthodes d'authentification et les scénarios dans lesquels elles interviennent.

MÉTHODES D'AUTHENTIFICATION DE CAS

Authentification OAuth Lorsque les clients SAS Viya se connectent à CAS, ils envoient le jeton d'accès OAuth de leur session, et CAS utilise ce jeton pour établir l'identité SAS Viya de sa session. Les clients open source peuvent obtenir un jeton OAuth à partir de SASLogon en utilisant son API REST ouvert, puis fournir le jeton à CAS pour l'authentification. Les clients CAS qui fournissent un jeton OAuth dans leur demande de connexion peuvent être catégorisés comme clients OAuth.

Le comportement par défaut pour les connexions CAS basées sur OAuth est de lancer des sessions CAS en utilisant l'ID de service configuré pour l'instance CAS concernée, qui, dans des déploiements typiques, sera un compte hôte appelé "cas". Les processus de session CAS sont la propriété de l'ID de service (par exemple, "cas"), ce qui établit un contexte de sécurité du fournisseur de données pour les caslibs basées sur le chemin dans l'identité de l'utilisateur hôte "cas".

Ce comportement par défaut peut être modifié, et ces options seront discutées dans la section sur la substitution du comportement de lancement de session CAS par défaut.

Authentification Externe (Hôte) Lorsque CAS reçoit un nom d'utilisateur et un mot de passe, au lieu d'un jeton d'accès OAuth, CAS tente d'acquérir un jeton d'accès SAS Viya auprès de SASLogon en utilisant le nom d'utilisateur et le mot de passe fournis pour l'authentification. Si CAS ne parvient pas à obtenir le jeton d'accès OAuth, la demande de connexion échoue. CAS effectue également une authentification au niveau de l'hôte, c'est-à-dire une authentification à travers la machine hôte sous-jacente.

Pour l'authentification de l'hôte sous Linux, CAS transmet le nom d'utilisateur et le mot de passe au sous-système PAM pour l'authentification. Si l'authentification réussit, CAS recherche l'UID dans le sous-système de services de noms (NSS) pour l'identification et d'autres attributs nécessaires au lancement de la session, tels que le répertoire de l'utilisateur. Si l'utilisateur est identifié, la connexion est établie, et la session est lancée au nom de l'utilisateur.

A noter que les deux processus Linux identsvcs et launchsvcs autorisent et lancent la session du serveur CAS. Ces services doivent être exécutés en tant que root car, sous Linux, l'identité de root est nécessaire pour démarrer un processus en cours sous une autre identité. Le processus launchsvcs crée une session CAS sous l'identité de l'utilisateur qui a soumis la demande. Le processus identsvcs authentifie les utilisateurs lorsqu'ils tentent de se connecter à un serveur CAS avec un nom d'utilisateur et un mot de passe à l'aide de PAM.

Le contexte de sécurité sortant de la session CAS sera dérivé de l'ID de l'utilisateur fourni. La session inclura un contexte de sécurité SAS Viya pour garantir un accès adéquat aux caslibs et aux tables chargées, ainsi qu'un contexte de sécurité du fournisseur de données basé sur l'ID de l'utilisateur utilisé pour l'authentification. Si le sous-système PAM sous-jacent est configuré pour l'authentification Kerberos, le contexte de sécurité du fournisseur de données de la session inclura également un accès à une autorisation Kerberos pour l'utilisateur.

FLUX DE DÉCISION POUR LE LANCEMENT DES SESSIONS CAS

Lorsque les clients de SAS Viya se connectent à CAS, ils envoient leur jeton d'accès OAuth de session, que CAS utilise pour établir l'identité SAS Viya de sa session. Les clients open source peuvent obtenir un jeton OAuth à partir de SASLogon en utilisant son API REST ouverte, puis fournir le jeton à CAS pour l'authentification. Les clients CAS qui fournissent un jeton OAuth dans leur demande de connexion peuvent être classés comme des clients OAuth.

Le comportement par défaut pour les connexions CAS basées sur OAuth est de lancer les sessions CAS en utilisant l'identifiant de service configuré pour l'instance CAS pertinente, qui dans des déploiements typiques sera un compte hôte appelé 'cas'. Les processus de la session CAS sont détenus par l'identifiant de service (par exemple, 'cas'), ce qui définit un contexte de sécurité du fournisseur de données pour les caslibs basées sur le chemin dans l'identité de l'utilisateur hôte 'cas'.

Ce comportement par défaut peut être modifié, et ces options seront discutées dans la section 'Modification du Comportement de Lancement par Défaut des Sessions CAS'.

Le processus de décision que le contrôleur CAS utilise pour déterminer comment lancer une session utilisateur :

• Pour l'authentification par mot de passe externe (lorsque CAS authentifie l'utilisateur via le sous-système PAM), l'utilisateur/le mot de passe est utilisé pour demander un jeton OAuth à SASLogon. Si le jeton peut être obtenu, la session est lancée en utilisant le justificatif d'identité de l'hôte représenté par le nom d'utilisateur, à condition que l'authentification PAM soit réussie. L'AUTHENTIFICATION PAM peut entraîner la création d'un cache de justificatifs Kerberos pour l'utilisateur, que CAS peut exploiter pour les caslibs se connectant à des sources de données Kerberos, telles que Hadoop
• Pour l'authentification OAuth, si l'utilisateur n'est pas membre du groupe CAS HOST ACCOUNT REQUIRED (c'est-à-dire si le lancement d'un hôte n'est pas demandé), les sessions seront lancées sous l'identité de l'utilisateur du compte de service CAS.
• Pour l'authentification OAuth lorsque l'utilisateur est membre du groupe CAS HOST ACCOUNT REQUIRED et que le CAS n'est pas configuré pour Kerberos : Si l'utilisateur a accès à un justificatif d'identité hôte valide (nom d'utilisateur et mot de passe) stocké dans SAS Viya, la session CAS est lancée à l'aide du justificatif d'identité stocké. Si l'utilisateur n'a pas accès à un identifiant stocké, les sessions CAS seront directement lancées à l'aide du nom d'utilisateur figurant sur le jeton OAuth, à condition qu'il s'agisse d'un compte hôte valide.
• Pour l'authentification OAuth, lorsque l'utilisateur est membre du groupe CAS HOST ACCOUNT REQUIRED et que le CAS est configuré pour Kerberos, le client est invité à rappeler avec Kerberos. configuré pour Kerberos, le CAS demande au client de rappeler avec une connexion Kerberos Kerberos. Si l'identifiant Kerberos de l'utilisateur (TGT) est transmis, le CAS l'utilise pour créer un cache d'identifiant Kerberos local pour l'utilisateur. pour créer un cache local de justificatifs Kerberos pour l'utilisateur. Le CAS lance la session dans l'identité hôte de l'utilisateur de l'utilisateur (sur la base du nom d'utilisateur figurant dans le jeton OAuth).

Remarque : si, lors de l'authentification, le lancement de l'hôte est demandé mais que l'utilisateur ou le mot de passe ne sont pas valides lorsque le CAS tente de les utiliser pour un lancement d'hôte (par exemple, si le fournisseur d'authentification d'hôte n'est pas correctement intégré avec le fournisseur LDAP configuré ou si un n'est pas correctement intégré au fournisseur LDAP configuré ou si un nom d'utilisateur ou un mot de passe incorrect a été fourni ou récupéré par le CAS). incorrect a été fourni ou récupéré par le système CAS), la session CAS ne sera pas lancée, en produisant une ERREUR dans le journal similaire à :

ERROR: OAuth user nhousset is not known on the host but requested host launch.

QUELQUES MESSAGES ET ERREURS

Le fichier journal du contrôleur CAS est un excellent moyen de confirmer ce que fait CAS en ce qui concerne les lancements de session. session. CAS écrit des messages de journal utiles au niveau INFO par défaut qui varient en fonction du type de client (OAuth, Password, Kerberos) et des informations d'identification fournies. selon le type de client (OAuth, Password, Kerberos) et les informations d'identification fournies.

Connexion de SAS Studio (Enterprise) au serveur Compute

INFO [00001850] MAIN NoUser MAIN [tkident.c:1323] - User nhousset successfully authenticated using the OAuth authentication provider.

Connecting from SAS Studio (Enterprise) launched Compute Server requesting Host launch

INFO [00002757] MAIN NoUser MAIN [tkidentoauth.c:737] - OAuth user sgf2020 requested host launch. INFO [00002757] MAIN NoUser MAIN [tkident.c:1323] - User
nhousset successfully authenticated using the OAuth authentication provider.

INFO [00002757] MAIN NoUser MAIN [tkcsesinst.c:748] - Successfully created session 8b87a764-916c-8a4e-b44d-907efe1fef42. INFO [00002757] MAIN sgf2020 329 [casgeneral.c:4824] - Launched session controller.

Connecting from an OAuthClient requesting Host launch, Kerberos.Enabled=True

INFO [00000106] MAIN NoUser MAIN [tkidentoauth.c:737] - OAuth user sgf2020 requested host launch. INFO [00000106] MAIN NoUser MAIN [tkident.c:1323] - User sgf2020 successfully authenticated using the OAuth authentication provider. INFO [00000106] MAIN NoUser MAIN [tkidentgss.c:976] - User sgf2020@TSAD.UNX.SAS.COM has authenticated using kerberos. INFO [00000106] MAIN NoUser MAIN [tkident.c:1323] - User sgf2020 successfully authenticated using the Kerberos authentication provider. INFO [00000106] MAIN NoUser MAIN [tkcsesinst.c:748] - Successfully created session 38644842-d16e-014a-a089-bb0241e4a38f. INFO [00000106] MAIN sgf2020 9 [casgeneral.c:4824] - Launched session controller. Process ID is 58227. sgf2020 58227 63911 0 04:35 ? 00:00:00 /opt/sas/viya/home/SASFoundation/utilities/bin/cas PASSWORD CLIENTS Connecting from a Workspace Server: SAS Studio 4.x or SAS Studio 5.2 (Basic) INFO [00002032] MAIN NoUser MAIN [tkident.c:1323] - User sgf2020 successfully authenticated using the OAuth authentication provider. INFO [00002032] MAIN NoUser MAIN [tkident.c:1323] - User sgf2020 successfully authenticated using the External PAM authentication provider

Voici enfin quelques messages et erreurs que vous pourriez trouver dans les logs :

ERROR [00417147] MAIN NoUser MAIN [tkclscommon.c:216] - pam_authenticate failed: Authentication failure (7).

Cette erreur survient lors d'une connexion à CAS avec un login utilisateur et un mot de passe. Le jeton OAuth a bien été obtenu mais PAM rejete la connexion.

ERROR [00313076] MAIN NoUser MAIN [tkclscommon.c:81] - Error writing request to external service: Broken pipe.

Cette erreur, plus rare, se produit lors d'une connexion à CAS avec un login utilisateur et un mot de passe. Le jeton OAuth a bien été obtenu mais lorsque que CAS souhaite passer les credential à l'OS, ce type d'erreur peut survenir. Le broken pipe indique que CAS ne parvient pas à accéder au binaire identsvcs. Ce binaire est un "process fils" de CAS. Verifier que ce process est bien présent.

GROS PLAN SUR LES BINAIRES SAS

caslaunch - Démarre un serveur CAS et ses processus de support (identsvcs et launchsvcs). Il ne lit et n'exécute qu'un simple fichier de configuration, qui est sous le contrôle de root.

Remarque : l'exigence setuid root s'applique à cet exécutable dans l'une des conditions suivantes : si les processus de session CAS s'exécutent sous l'identité d'un utilisateur individuel ou si les processus de session CAS s'authentifient auprès d'une source nécessitant un accès root. La configuration PAM peut ne pas nécessiter de privilèges root.

elssrv - Lance les processus via l'identité du client demandeur ou via un ensemble d'informations d'identification stockées.

sasauth - Permet aux serveurs SAS Viya d'authentifier les clients qui se connectent.

CONCLUSION

SAS Viya est une application complexe qui offre de nombreuses façons d'obtenir des insights à partir des données tout en ouvrant simultanément de nombreuses voies vers des sources de données externes et des données résidentes dans le moteur d'analyse CAS.

La conformité aux politiques d'accès aux données est également une entreprise complexe et une préoccupation constante pour les organisations dans le monde technologique d'aujourd'hui.

Pour concevoir votre environnement SAS Viya de manière à donner aux utilisateurs des moyens pour obtenir des insights tout en répondant aux exigences strictes de conformité aux politiques de données, il est nécessaire de comprendre en profondeur comment SAS Viya permet l'accès aux données et offre des fonctionnalités pour en contrôler l'accès.

Dans cet article, nous avons examiné en détail comment SAS Viya permet l'accès aux sources de données dans une configuration 'prête à l'emploi'.

Nous avons également examiné toutes les façons dont une configuration par défaut peut être améliorée pour s'aligner et s'intégrer mieux dans divers contextes technologiques.

Il n'y a pas de solution simple, mais espérons que les idées présentées seront utiles pour guider les activités de conception nécessaires pour créer une solution personnalisée répondant aux besoins de votre organisation.

POUR ALLER PLUS LOIN

Rogers, Stuart. “SAS Viya 3.4 Kerberos with CAS”. 2018. December 22, 2018.
https://communities.sas.com/t5/SAS-Communities-Library/SAS-Viya-3-4-Kerberos-withCAS/ta-p/523246

Rogers, Stuart. 2020. “SAS Viya 3.5 Compute Server Service Accounts”.
https://communities.sas.com/t5/SAS-Communities-Library/SAS-Viya-3-5-Compute-ServerService-Accounts/ta-p/620992

SAS Institute Inc. 2019. SAS Micro Analytic Service 5.4: Programming and Administration Guide. Cary, NC: SAS Institute Inc.
https://documentation.sas.com/?docsetId=masag&docsetTarget=p0gehkxmerovitn1w5nv6y vgpws5.htm&docsetVersion=5.4

SAS Institute Inc. 2019. SAS Viya 3.5 Administration. Cary, NC: SAS Institute Inc.
http:// https://documentation.sas.com/?cdcId=calcdc&cdcVersion=3.5&docsetId=calwlcm&docsetT arget=home.htm

SAS® Cloud Analytic Services Sessions: Understanding Connection Options to Ensure Data Access Security https://support.sas.com/resources/papers/proceedings20/4613-2020.pdf