Jamf Concepts
Guides

Guides

Restriction de l'accès pour les appareils anonymes

~6 min read

Une fois que vous avez activé l'accès pour les appareils de confiance – créant des routes sécurisées vers vos applications et sources de données sur site et dans le cloud – vous pouvez maintenant commencer à verrouiller vos sources de données en empêchant l'accès aux appareils « anonymes ».

Un appareil anonyme est tout appareil qui n'est pas approuvé par votre organisation. Cela comprend :

  • L'ordinateur portable d'un attaquant
  • Un iPhone personnel qui n'est pas inscrit en tant qu'utilisateur
  • L'ordinateur portable d'un conjoint
  • Un PC de café

Il est plus important que jamais de restreindre l'accès aux appareils de confiance uniquement, mais cela est compliqué par le cloud et le travail à distance où le périmètre « sur site » a disparu. Néanmoins, la solution et l'architecture Trusted Access exigent de soutenir le verrouillage de toutes les sources de données, y compris sur site et dans le cloud.

Verrouillage des ressources sur site / centre de données

De nombreuses organisations hébergent une part importante de leurs applications et données sensibles sur des serveurs qui sont sous leur contrôle et gestion directs. Ces serveurs sont installés dans une installation privée ou un centre de données correctement sécurisé.

Heureusement, ces applications existent déjà derrière un pare-feu, les masquant déjà de l'accès interne ouvert. Cependant, il y a quelques points à vérifier :

  • Supprimez les adresses IP publiques mappées (dans une plage CIDR émise par un FAI) du serveur de destination. Les serveurs ne doivent être accessibles que via des adresses IP privées.
    • Supprimez toute exception NAT 1 vers 1 ou de trou de pare-feu qui mappe les connexions d'une adresse IP publique vers la ou les adresses IP internes du serveur. C'est particulièrement important pour les protocoles risqués comme HTTP et RDP.
  • Si l'application est particulièrement sensible, configurez les ACL réseau (listes de contrôle d'accès) soit sur le ou les serveurs, soit sur le réseau local pour autoriser les connexions entrantes de l'application uniquement à partir du sous-réseau Jamf tel que défini dans les paramètres du domaine de chiffrement de votre interconnexion IPSec.

Les utilisateurs de confiance et leurs appareils accéderont à ces ressources via une passerelle d'interconnexion IPSec personnalisée, qui sera facilement accessible avec Jamf Trust déployé et activé sur leur appareil.

Verrouillage des ressources Infrastructure as a Service (IaaS)

Infrastructure as a Service est défini comme des services cloud fournis par des fournisseurs tiers qui vous permettent d'exécuter vos applications et de stocker vos données sans avoir à gérer l'infrastructure physique elle-même. Les plateformes IaaS les plus courantes sur le marché sont Amazon Web Services, Google Cloud Platform et Microsoft Azure.

Restreindre l'accès aux ressources dans ces environnements est en fait très similaire aux ressources sur site / centre de données en ce que les ressources sont généralement configurées sur des réseaux virtuels privés au sein du fournisseur IaaS. Cependant, la grande différence est qu'il est beaucoup plus courant que les applications et ressources de données soient rendues publiquement disponibles. Qu'intentionnellement ou accidentellement (puisque c'est facile à faire !), cet accès trop ouvert a été la cause profonde de nombreux piratages importants ces dernières années.

Les utilisateurs et appareils de confiance peuvent accéder à ces ressources en utilisant l'une des options d'interconnexion suivantes :

Verrouillage des ressources Software as a Service (SaaS)

Software as a Service est défini comme des applications que vous avez achetées mais dont vous ne possédez pas l'exploitation de quelque manière que ce soit. Les services SaaS métier courants incluent Microsoft 365, Salesforce, Slack, Box et Zoom. Il y a de bonnes chances que votre organisation possède au moins une application SaaS et qu'elle contienne des données d'entreprise sensibles !

Cependant, sans contrôle natif de l'infrastructure sous-jacente de l'application SaaS – y compris les connexions réseau – vous êtes à la merci du fournisseur SaaS pour fournir (ou non) des contrôles d'accès qui peuvent être utilisés pour identifier un utilisateur et un appareil autorisés.

Il existe généralement deux techniques disponibles pour verrouiller l'accès aux applications SaaS : via l'adresse IP source ou le fournisseur d'identité (IdP).

Utilisation de l'adresse IP source

Certains fournisseurs SaaS permettent aux clients individuels de définir les plages d'adresses IP source autorisées à se connecter à leur client spécifique pour accéder à l'application ou au service SaaS. Bien que relativement rare, le verrouillage par adresse IP source est un moyen fiable d'autoriser l'accès uniquement à partir d'appareils se connectant via l'infrastructure Jamf Private Access.

Vous pouvez utiliser les adresses IP globales partagées de Jamf ou une adresse IP publique de l'autre côté d'une passerelle d'interconnexion IPSec personnalisée.

Un exemple puissant de ceci est l'utilisation des règles d'accès du client d'accès pour limiter la connectivité Microsoft Exchange aux appareils activés pour Private Access uniquement.

Utilisation d'un fournisseur d'identité

La plupart des fournisseurs SaaS supportent l'authentification unique, qui utilise le fournisseur d'identité de votre organisation (p. ex. Okta, Azure AD) pour autoriser ou refuser l'accès à cette application, au lieu de compter sur un ensemble distinct d'identifiants. Bien que ce soit excellent pour l'identité de l'utilisateur, les fournisseurs SaaS offrent rarement des contrôles d'accès appareil.

Heureusement, les fournisseurs d'identité offrent une prise en charge de la sensibilisation au niveau de l'appareil que nous pouvons utiliser pour distinguer un appareil autorisé d'un appareil non autorisé.

Via l'adresse IP source Jamf

Les trois principaux IdP du marché supportent la définition de politiques d'accès de connexion qui considèrent l'adresse IP source comme un critère pour pouvoir se connecter à une application SaaS donnée.

En utilisant ce critère, vous pouvez utiliser les adresses IP cloud de Jamf comme moyen d'identifier si une connexion entrante provient d'un appareil sur lequel Private Access est déployé et actif. Un appareil non autorisé ne présentera pas d'adresse IP appartenant à Jamf Security Cloud, et sera donc bloqué par la politique d'accès des IdP.

Pour des détails sur la configuration de ceci pour votre IdP, consultez ces guides :

Vous pouvez voir à quoi ressemble cette expérience sur la vidéo de démonstration BYOD trouvée ici.

Via une application/agent de point de terminaison IdP

Certains IdP fournissent des applications/agents de point de terminaison qui peuvent être utilisés pour fournir l'identité d'appareil et l'authentification dans le cadre du processus de connexion. Bien que cette méthode soit meilleure que l'utilisation d'adresses IP source, elle nécessite des considérations et des complexités de déploiement et d'activation supplémentaires.