DotW: eingeschränkter Zugriff auf die API

DotW: eingeschränkter Zugriff auf die API

23058
Created On 09/25/18 19:05 PM - Last Modified 06/01/23 09:27 AM


Resolution


Ist es möglich, den Zugriff auf die API einzuschränken? Was sind die besten Praktiken, um zu verhindern, dass ein API-Schlüssel von einem anderen Rechner benutzt wird, um auf die Firewall zuzugreifen? In der Diskussion der Woche in dieser Woche schauen wir uns eine Frage an, die Community-Mitglied XavierMe nach dem Zugriff auf die API gestellt hat.

 

2015-12 -28 _13-26 -18. png

 

Die API ist Teil der Funktionen, die auf einer Management-Schnittstelle verfügbar sind, und der Zugriff auf die Managementfunktionen kann auf verschiedene Weise gesteuert und eingeschränkt werden:

 

Die einfachsten Einschränkungen können durch die Konfiguration der Management-Interface-Einstellungen und der Interface-Management-Profile festgelegt werden, um nur bestimmte Dienste wie SSH und SSL zu ermöglichen, aber keine Telnet oder andere unnötige Dienste zuzulassen. Die API ist nur auf der Web-Schnittstelle verfügbar, so dass Sie HTTP/HTTPS auf jeder Schnittstelle deaktivieren können, wo Sie nicht benötigt wird, und nur SSH verwenden. Sie können auch den Zugriff auf Management-Dienste auf der Grundlage von Source IP oder Subnet einschränken, um zu verhindern, dass unerlaubte Netzwerke vollständig auf die Dienste zugreifen.

 

Management Interface

 

Wenn mehrere verschiedene Administratoren Zugriff auf die Firewall benötigen, aber einige nicht berechtigt sind, auf die API zuzugreifen, können Sie mit Hilfe von admin-Rollen weiter kontrollieren, welche Aktionen verfügbar sind und was für jede Gruppe von Administratoren sichtbar oder unsichtbar ist. Teile der GUI können nur lesbar oder unsichtbar gemacht werden. Einige Protokoll Ausgänge können anonym gemacht werden, so dass ein Administrator in der Lage sein kann, Protokolle zur Fehlerbehebung zu verwenden, aber keine Benutzer Aufzählung:

 

GUI Web UI

 

Der Zugriff auf die API kann auch für einen Admin völlig unmöglich gemacht werden, oder es werden nur benötigte Teile zur Verfügung gestellt. Zum Beispiel ist es einem Betreiber erlaubt, Berichte zu sammeln oder die Protokollierung anzuzeigen, aber keine Konfigurationsänderungen vorzunehmen oder operative Befehle über die API auszuführen. Ein automatisiertes User-ID-Skript kann User-to-IP-Mapping hinzufügen oder entfernen, aber das Konto kann nicht für den Zugriff auf andere API-Funktionen verwendet werden:

 

API

 

Auf die gleiche Weise kann ein Administrator auch keinen CLI-Zugriff, keinen nur lesbaren Zugriff oder eingeschränkten Betriebs-oder Superuser-Zugriff haben:

 

CLI

 

Wenn schließlich der "Role"-funkknopf auf virtuelles System umgestellt wird, können alle oben genannten Einschränkungen nur innerhalb der zugewiesenen VSYS wirksam gemacht werden, während die restlichen VSYS für den Administrator unzugänglich sind. Im Szenario eines Shared-Service-Providers oder administrativer Grenzen zwischen den Teams kann dies Administratoren vollen Zugriff innerhalb ihrer eigenen VSYS ermöglichen, ohne versehentlich einen anderen Kunden oder Team-VSYS zu stören.

 

Vsys rollenbasierte admin

 

 

Ich hoffe, Sie fanden diese Erklärung hilfreich. Sie können die ursprüngliche Diskussion hier verfolgen oder Kommentare im Kommentarbereich unten hinzufügen .

 

Herzliche Grüße

Tom

 

 



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClU0CAK&lang=de&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language