Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Choix de l'affichage du bureau ou de l'affichage des applications

Le choix d'une vue d'application ou d'une vue de bureau n'a aucun impact sur les performances ou les coûts. Une seule vue est accessible à la fois par parc WorkSpaces d'applications. Vous pouvez modifier l'option Stream view. Planifiez ce changement pendant les heures creuses, car la modification de la vue du stream nécessite un redémarrage de la flotte.

Il n'existe pas de meilleure pratique unique pour l'affichage des flux. L'impact des options d'affichage des flux est résumé comme suit :

Vue du bureau

Dans les cas d'utilisation où tout le flux de travail de l'utilisateur est effectué en session, Desktop View simplifie l'expérience utilisateur en centralisant toutes les applications dans un seul environnement. Desktop View peut offrir une expérience utilisateur plus cohérente pour les déploiements de plus de 3 à 5 applications nécessitant une intégration au système d'exploitation (OS). Desktop View est efficace lorsque vous gérez deux environnements séparés et distincts. Par exemple, un utilisateur peut avoir accès simultanément à un environnement de bureau de production et de pré-production pour valider les modifications apportées à la mise en page, à la configuration et à l'accès aux applications.

WorkSpaces Les rapports d'utilisation des applications créent un rapport quotidien sur les applications pour Desktop View. Le résultat obtenu pour l'application est simplement « bureau », mappé directement à la session WorkSpaces Applications. Pour plus d'informations, reportez-vous à la section Surveillance de l'utilisation des utilisateurs de ce document.

Afficher uniquement les applications

La vue Applications uniquement est également efficace lorsque la pile WorkSpaces Applications est destinée à fournir quelques applications requises par intermittence. Dans les environnements de kiosque, la diffusion des applications est verrouillée de manière sécurisée via Application View. Avec Application View, WorkSpaces Applications remplace le shell Windows par défaut par un shell personnalisé. Ce shell personnalisé ne présente que les applications en cours d'exécution, minimisant ainsi la surface d'attaque du système d'exploitation.

Dans les cas d'utilisation où WorkSpaces les applications sont utilisées pour améliorer l'environnement de bureau d'une organisation existante, l'affichage Applications uniquement est préférable. Déployez le client WorkSpaces Applications Windows en mode application natif afin de minimiser la confusion chez les utilisateurs en permettant l'utilisation complète des raccourcis clavier.

Amazon WorkSpaces Applications Usage Reports crée un rapport quotidien sur les applications à consulter. Pour des rapports plus précis sur l'utilisation des applications et des exécutions, envisagez une solution tierce pour établir des rapports au niveau du système d'exploitation. Vous pouvez utiliser Microsoft AppLocker en mode reporting ou envisager des solutions disponibles dans le AWS Marketplace, telles que Stratusphere UX de Liquidware.

Gestion des identités et des accès AWS configuration des rôles

Si une charge de travail nécessite que les utilisateurs finaux des WorkSpaces applications accèdent à d'autres AWS services depuis leur session, il est recommandé de déléguer l'accès à l'aide de rôles Gestion des identités et des accès AWS (IAM). Les rôles IAM peuvent être directement associés à la session de votre utilisateur final par le biais de l'attribution au niveau de la flotte. Pour connaître les meilleures pratiques supplémentaires relatives à l'utilisation de rôles IAM avec WorkSpaces des applications, consultez cette section du guide de l'administrateur.

Utilisation d'informations d'identification statiques

Certaines charges de travail peuvent nécessiter des entrées statiques pour les clés d'accès IAM au lieu de les hériter du rôle attaché. Il existe deux méthodes pour recevoir ces informations d'identification. La première méthode consiste à stocker les clés d'accès dans un AWS service, puis à donner à vos utilisateurs finaux un accès IAM explicite pour extraire cette valeur spécifique du service. Deux exemples de mécanismes de stockage de clés d'accès utilisent AWS Secrets Managerou AWS SSM Parameter Store. La deuxième méthode consiste à utiliser le fournisseur d'informations d'identification WorkSpaces Applications pour accéder aux clés d'accès du rôle attaché. Cela peut être fait en invoquant le fournisseur d'informations d'identification et en analysant la sortie pour votre clé d'accès et votre clé secrète. Voici un exemple de la manière d'effectuer cette PowerShell action.

$CMD = 'C:\Program Files\Amazon\Photon\PhotonRoleCredentialProvider\PhotonRoleCredentialProvider.exe'
$role = 'Machine'

$output = & $CMD --role=$role
$parsed = $output | ConvertFrom-Json

$access_key = $parsed.AccessKeyId
$secret_key = $parsed.SecretAccessKey
$session_token = $parsed.SessionToken

Protection du compartiment S3 de vos WorkSpaces applications

Si la charge de travail de vos WorkSpaces applications est configurée avec la persistance des and/or applications dans le dossier d'accueil, il est recommandé de protéger le compartiment Amazon S3 dans lequel les données persistantes sont stockées contre tout accès non autorisé ou toute suppression accidentelle. La première couche de protection consiste à ajouter une politique de compartiment Amazon S3 afin d'empêcher la suppression accidentelle du compartiment. Le deuxième niveau de protection consiste à ajouter une politique de compartiment conforme au principe du moindre privilège. L'alignement sur le principe peut être effectué en autorisant uniquement l'accès au bucket aux parties nécessaires.