Jamf Concepts
Anleitungen

Anleitungen

Zugriff für anonyme Geräte einschränken

~5 min read

Nachdem Sie den Zugriff für vertrauenswürdige Geräte aktiviert haben – wodurch sichere Routen zu Ihren Anwendungen und Datenquellen vor Ort und in der Cloud entstehen – können Sie nun damit beginnen, Ihre Datenquellen zu sichern, indem Sie den Zugriff „anonymer" Geräte verhindern.

Ein anonymes Gerät ist jedes Gerät, das von Ihrer Organisation nicht genehmigt wurde. Dies umfasst:

  • Den Laptop eines Angreifers
  • Ein persönliches iPhone, das nicht mit User Enrollment registriert ist
  • Den Laptop eines Ehepartners
  • Einen PC in einem Café

Es ist wichtiger denn je, den Zugriff auf vertrauenswürdige Geräte zu beschränken, aber dies wird durch Cloud und Remote Work erschwert, wo die „lokale" Perimeterkontrolle verschwunden ist. Dennoch erfordert die Trusted Access-Lösung und -Architektur die Unterstützung der Abschottung aller Datenquellen, einschließlich lokaler und Cloud-Ressourcen.

Sicherung lokaler / Rechenzentrumsressourcen

Viele Organisationen hosten einen erheblichen Teil ihrer sensiblen Anwendungen und Daten auf Servern, die sich unter ihrer direkten Kontrolle und Verwaltung befinden. Diese Server sind in einer privaten Einrichtung oder in einem ordnungsgemäß gesicherten Rechenzentrum installiert.

Glücklicherweise befinden sich diese Anwendungen bereits hinter einer Firewall, die sie vor unbefugtem internem Zugriff schützt. Es gibt jedoch einige Dinge zu überprüfen:

  • Entfernen Sie alle zugeordneten öffentlichen IPs (innerhalb eines von Ihrem ISP vergebenen CIDR-Bereichs) vom Zielserver. Server sollten nur über private IP-Adressen erreichbar sein.
    • Entfernen Sie alle 1-zu-1-NAT- oder Firewall-Pinhole-Ausnahmen, die Verbindungen von einer öffentlichen IP-Adresse zur internen IP-Adresse des Servers zuordnen. Dies ist besonders wichtig für riskante Protokolle wie HTTP und RDP.
  • Wenn die Anwendung besonders sensibel ist, konfigurieren Sie Network ACLs (Access Control Lists) entweder auf den Servern oder im LAN so, dass nur Anwendungsverbindungen vom Jamf-Subnetz zulässig sind, wie in den Encryption Domain-Einstellungen Ihrer IPSec-Verbindung definiert.

Vertrauenswürdige Benutzer und ihre Geräte können auf diese Ressourcen über ein Custom IPSec Interconnect Gateway zugreifen, das nahtlos erreichbar ist, sobald Jamf Trust auf ihrem Gerät bereitgestellt und aktiviert wird.

Sicherung von Infrastructure as a Service (IaaS)-Ressourcen

Infrastructure as a Service wird als Cloud-basierte Dienste von Drittanbietern definiert, die es Ihnen ermöglichen, Ihre Anwendungen auszuführen und Ihre Daten zu speichern, ohne die physische Infrastruktur selbst verwalten zu müssen. Die am häufigsten genutzten IaaS-Plattformen sind Amazon Web Services, Google Cloud Platform und Microsoft Azure.

Das Einschränken des Zugriffs auf Ressourcen in diesen Umgebungen ist tatsächlich sehr ähnlich wie bei lokalen / Rechenzentrumsressourcen, da Ressourcen normalerweise in privaten virtuellen Netzwerken innerhalb des IaaS-Anbieters konfiguriert werden. Der große Unterschied besteht jedoch darin, dass es viel häufiger vorkommt, dass Anwendungen und Datenressourcen öffentlich verfügbar gemacht werden. Ob absichtlich oder versehentlich (da dies leicht möglich ist!), dieser übermäßig offene Zugriff war in den letzten Jahren die Ursache für viele bedeutende Sicherheitsverletzungen.

Vertrauenswürdige Benutzer und Geräte können auf diese Ressourcen mithilfe einer der folgenden Verbindungsoptionen zugreifen:

Sicherung von Software as a Service (SaaS)-Ressourcen

Software as a Service wird als Anwendungen definiert, die Sie gekauft haben, aber deren Betrieb Sie in keiner Weise kontrollieren. Häufige Business-SaaS-Dienste sind Microsoft 365, Salesforce, Slack, Box und Zoom. Es ist sehr wahrscheinlich, dass Ihre Organisation mindestens eine SaaS-App hat, die sensible Unternehmensdaten enthält!

Ohne native Kontrolle über die zugrunde liegende Infrastruktur der SaaS-App – einschließlich Netzwerkverbindungen – sind Sie jedoch darauf angewiesen, dass der SaaS-Anbieter Zugriffskontrolls bereitstellt (oder nicht), die verwendet werden können, um einen genehmigten Benutzer und ein genehmigtes Gerät zu identifizieren.

Es gibt generell zwei Techniken, um den Zugriff auf SaaS-Apps zu sichern: über die Quell-IP oder den Identity Provider (IdP).

Verwendung von Quell-IP-Adressen

Einige SaaS-Anbieter ermöglichen es einzelnen Kunden, die Quell-IP-Adressbereiche zu definieren, die für die Anmeldung bei ihrem spezifischen Kundenmandanten für den Zugriff auf die SaaS-Anwendung oder den Dienst zulässig sind. Obwohl relativ selten, ist die Quell-IP-Abschottung eine zuverlässige Möglichkeit, um nur Zugriff von Geräten zu ermöglichen, die sich über die Jamf Private Access-Infrastruktur verbinden.

Sie können Jamfs gemeinsame globale IP-Adressen oder eine öffentliche IP auf der anderen Seite eines Custom IPSec Interconnect Gateway verwenden.

Ein leistungsstarkes Beispiel ist die Verwendung von Access Client Access Rules zur Begrenzung der Microsoft Exchange-Konnektivität auf nur Private Access-aktivierte Geräte.

Verwendung eines Identity Providers

Die meisten SaaS-Anbieter unterstützen Single Sign On, das Ihren organisationseigenen Identity Provider (z. B. Okta, Azure AD) verwendet, um den Zugriff auf diese Anwendung zu gewähren oder zu verweigern, anstatt sich auf einen separaten Satz von Anmeldedaten zu verlassen. Während dies großartig für die Benutzer-Identität ist, bieten SaaS-Anbieter selten Geräte-Zugriffskontrolls.

Glücklicherweise bieten Identity Provider Unterstützung für Geräteebenen-Erkennung, die wir verwenden können, um ein genehmigtes Gerät von einem nicht genehmigten zu unterscheiden.

Über Jamf Quell-IP

Die drei führenden IdPs auf dem Markt unterstützen die Definition von SSO-Zugriffsrichtlinien, die die Quell-IP-Adresse als Kriterium für die Anmeldung bei einer bestimmten SaaS-App berücksichtigen.

Mit diesem Kriterium können Sie Jamfs Cloud-IP-Adressen verwenden, um festzustellen, ob eine eingehende Anmeldung von einem Gerät mit aktivem Private Access stammt. Ein nicht autorisiertes Gerät wird keine Quell-IP von Jamf Security Cloud aufweisen und wird daher durch die IdP-Zugriffsrichtlinie blockiert.

Weitere Informationen zur Konfiguration für Ihren IdP finden Sie in folgenden Leitfäden:

Sie können sich anschauen, wie diese Erfahrung aussieht, indem Sie das BYOD-Demovideo hier ansehen.

Über eine IdP Endpoint-App/einen IdP-Agenten

Einige IdPs stellen Endpoint-Apps/Agenten bereit, die verwendet werden können, um Geräteidentität und -authentifizierung als Teil des Anmeldeprozesses bereitzustellen. Obwohl diese Methode besser ist als die Verwendung von Quell-IPs, erfordert sie zusätzliche Bereitstellungs- und Aktivierungsüberlegungen und Komplexitäten.