Wie aktualisieren Unternehmen ihre Firewall nach einer Änderung der Xcode Cloud-Ausgangs-IP? 2026

Entscheidungsrahmen: Aktualisieren Sie die Firewall- und Repository-Allowlist nur anhand der aktuell von Apple veröffentlichten Xcode-Cloud-IP-Bereiche und bestätigen Sie die Änderung mit einem realen Workflow. Verlassen Sie sich weder auf alte interne Listen noch auf ungeprüfte IP-Angaben Dritter.

Dieser Leitfaden ist für IT-Netzwerkverantwortliche gedacht, die Firewall- oder Gateway-Regeln pflegen, sowie für Sicherheitsfachleute, die Änderungen prüfen und freigeben. Auch Administratoren selbst gehosteter Git-Dienste und anderer Code-Repositories erfahren, welche Netzwerk- und Berechtigungsprüfungen sie getrennt durchführen müssen.

Zuletzt geprüft am 26.10.2026: Apples Veröffentlichungshinweise dokumentieren eine Änderung des Xcode-Cloud-Ausgangs-IP-Bereichs am 10.02.2026. Die Adressen und ihre Anwendbarkeit sollten Sie weiterhin anhand der aktuellen Xcode-Cloud-Veröffentlichungshinweise und der Dokumentation zur Projekteinstellung prüfen. Diese Quellen sind die Grundlage; ob Ihre Regeln tatsächlich angepasst wurden und greifen, kann nur Ihr Team kontrollieren.

Zuständigkeiten vor der Änderung klären

Eine IP-Änderung betrifft nicht automatisch jede Verbindung Ihres CI-Systems. Ermitteln Sie zunächst, ob die Störung beziehungsweise die notwendige Anpassung den Weg von Xcode Cloud zum Repository betrifft oder ob eine andere Verbindung in Ihrem Aufbau betroffen ist. Prüfen Sie dafür den Fehlerkontext und die bestehenden Regeln, bevor Sie Änderungen an einer größeren Menge von Netzwerkfreigaben beantragen.

Die Aufgaben sind voneinander abhängig, aber nicht austauschbar. Ein erfolgreich geänderter Firewall-Eintrag bestätigt noch nicht, dass die Repository-Verbindung korrekt eingerichtet ist. Umgekehrt beweist eine gültige Anmeldung nicht, dass ein Netzwerkfilter die Verbindung durchlässt.

Bei Xcode Cloud sind die veröffentlichten IP-Bereiche der Ausgangspunkt für die Freigabe. Apples Anleitung zur Einrichtung der Quellcodeverwaltung beschreibt außerdem den Zusammenhang zwischen einer Repository-Verbindung und der Zugriffseinrichtung. Behandeln Sie diese beiden Fragen daher als getrennte Prüfpunkte.

Auswirkungen auf die Allowlist eingrenzen

Die Änderung ist nicht die Aufforderung, Regeln pauschal zu öffnen. Vergleichen Sie Ihre vorhandenen Regelobjekte mit den aktuellen Apple-Angaben und bestimmen Sie, welche davon den Zugriff von Xcode Cloud auf das tatsächlich verwendete Repository begrenzen. Prüfen Sie dabei die von Apple dokumentierten IPv4- und IPv6-Bereiche; übernehmen Sie keine Adresse, die sich nicht in der aktuellen offiziellen Referenz nachvollziehen lässt.

Für eine Xcode-Cloud-IP-Änderung genügt es nicht, den Eintrag in einer Firewall-Konsole zu ersetzen. Je nach Unternehmensaufbau können Freigaben an mehreren Stellen verwaltet werden: etwa in einem Gateway, einer vorgelagerten Netzwerksteuerung oder in den Zugriffseinstellungen des Code-Repositorys. Erstellen Sie deshalb zuerst eine Bestandsaufnahme, die Regelname, betroffenes Ziel, verantwortliches Team und den verwendeten Änderungsprozess festhält. Das hilft, doppelte oder widersprüchliche Freigaben zu erkennen.

Eine Unternehmens-Firewall-Allowlist sollte auf den notwendigen Zugriff begrenzt bleiben. Legen Sie fest, welche Quellen Apple offiziell nennt, welches Repository erreichbar sein muss und welche Regel dafür zuständig ist. Prüfen Sie, ob Änderungen an den zentralen Regelobjekten tatsächlich an die relevanten Durchsetzungspunkte verteilt werden. Eine Benutzeroberfläche mit gespeichertem Eintrag ist allein kein Nachweis für eine wirksame Regel.

Wichtig: Eine IP-Freigabe schafft keine Repository-Berechtigung. Halten Sie Netzwerkfreigabe, Authentifizierung und Rechte auf den Quellcode getrennt fest. Die Apple-Sicherheitshinweise zu Xcode Cloud liefern den offiziellen Sicherheitskontext; die tatsächliche Wirkung Ihrer Unternehmensregeln müssen Sie in Ihrer eigenen Umgebung prüfen.

Für die dokumentierte Abgrenzung von Sicherheitsmaßnahmen können Sie außerdem den Katalog der Sicherheitskontrollen heranziehen. Er ersetzt weder Ihre Risikobewertung noch die Freigabe durch Ihre Sicherheitsverantwortlichen. Er kann aber dabei helfen, Änderungsnachweis, Zugriffskontrolle und Verantwortlichkeit in Ihren internen Prozess einzuordnen.

Entscheidungspfad für den Änderungsumfang

• Wenn Apples aktuelle Dokumentation einen passenden Bereich für den betroffenen Zugriff nennt und Sie eine vorhandene Regel eindeutig diesem Repository zuordnen können, dann ändern Sie gezielt diese Regel und dokumentieren Sie die Grundlage.
• Wenn mehrere Regelobjekte infrage kommen oder das betroffene Ziel unklar ist, dann halten Sie die Änderung an und klären Sie den Netzwerkpfad zuerst mit den zuständigen Teams.
• Wenn ein Fehler auch nach der Regeländerung auftritt, dann weiten Sie die Quelle nicht sofort auf beliebige Adressen aus. Prüfen Sie zunächst Regelverteilung, Repository-Autorisierung und Workflow-Konfiguration getrennt.
• Wenn Sie die offizielle Adressgrundlage nicht eindeutig bestätigen können, dann übernehmen Sie keine Drittanbieter-Liste. Beschaffen Sie die aktuelle Apple-Angabe, bevor Sie die Freigabe beantragen.

Netzwerkverantwortliche: Regeln kontrolliert ändern

Erfassen Sie vor dem Eingriff den Ist-Zustand. Dazu gehören die Regelobjekte, ihre Ziele, der Zweck der jeweiligen Freigabe und der letzte bekannte Änderungs- oder Genehmigungsnachweis. Prüfen Sie, ob eine vorhandene Regel ausdrücklich den Zugriff von Xcode Cloud auf das Repository abdeckt oder ob sie Teil einer allgemeineren Netzwerkregel ist. Diese Unterscheidung verhindert, dass ein eng begrenzter Zugriff versehentlich in eine umfassende Ausnahme umgewandelt wird.

1. Offizielle Quelle bestätigen. Öffnen Sie Apples aktuelle Projektdokumentation und die Veröffentlichungshinweise. Notieren Sie, welches Dokument die IP-Bereiche aufführt und wann die Änderung laut Veröffentlichungsnotizen bekannt gegeben wurde. Erfassen Sie auch den Zeitpunkt Ihrer Prüfung, damit spätere Audits zwischen Apples Veröffentlichung und Ihrer internen Änderung unterscheiden können.
2. Betroffene Regelobjekte identifizieren. Suchen Sie nach Regeln, die das betreffende Repository oder den dafür eingesetzten Zugriffspfad begrenzen. Prüfen Sie Firewall und Gateway ebenso wie vorhandene IP-Beschränkungen auf der Repository-Seite. Eine allgemeine Regel mit ähnlichem Namen ist kein ausreichender Beleg dafür, dass sie für diesen Datenverkehr zuständig ist.
3. Änderung beantragen und begrenzen. Verwenden Sie in Ihrem Änderungsantrag die offizielle Quelle, die betroffene Regel, das Zielsystem und den erforderlichen Umfang. Nehmen Sie nur jene Quellbereiche auf, die für die geplante Verbindung notwendig und durch Apple belegt sind. Halten Sie zugleich fest, wie sich die Änderung zurücknehmen lässt.
4. Freigabe nach internem Prozess einholen. Lassen Sie die zuständigen Sicherheits- und Netzwerkverantwortlichen Umfang und Begründung prüfen. Der Freigabeprozess sollte klären, wer die Änderung ausführt und wer bei unerwarteten Auswirkungen die Rücknahme veranlasst.
5. Regeländerung und Verteilung kontrollieren. Vergleichen Sie nach der Änderung den tatsächlich gespeicherten Eintrag mit dem genehmigten Antrag. Prüfen Sie in Ihren eigenen Systemen, ob die Regel an den vorgesehenen Durchsetzungspunkten angekommen ist. Welche Systeme und Kontrollanzeigen dafür maßgeblich sind, hängt von Ihrer Umgebung ab.
6. Zugriff mit dem CI-Verantwortlichen testen. Bestätigen Sie nicht nur, dass ein Regelobjekt gespeichert wurde. Lassen Sie einen passenden Xcode-Cloud-Workflow ausführen und bewerten Sie das Ergebnis zusammen mit den Repository-Verantwortlichen.
7. Nachweis und Rückfallverantwortung festhalten. Archivieren Sie die Quelle, die Freigabe, die Änderung und das Prüfergebnis gemeinsam. Benennen Sie klar, wer bei einem Fehlschlag die Rücknahme entscheidet und wer die nächsten Prüfungen übernimmt.

Halten Sie für das Änderungsprotokoll ein Format fest, das zu Ihrem Prozess passt. Die folgende Struktur ist ein Beispiel für eine interne Prüfnnotiz, keine Apple-Schnittstelle und kein Nachweis für eine tatsächlich erfolgreiche Verbindung:

Prüfgegenstand:      Xcode-Cloud-Zugriff auf das betroffene Repository
IP-Quelle:           aktuelle Apple-Projektdokumentation
Geprüfte Regel:      <interner Regelname oder Änderungs-ID>
Änderungsfreigabe:   <interner Genehmigungsnachweis>
Workflow-Ergebnis:   <bestätigt / fehlgeschlagen / nicht ausgeführt>
Rückfallverantwortung: <zuständiges Team oder Rolle>

Füllen Sie das Feld zum Workflow-Ergebnis erst nach einem tatsächlichen Test aus. Trennen Sie einen gespeicherten Änderungsantrag von einer angewandten Regel und wiederum von einer erfolgreich geprüften Repository-Verbindung.

Repository-Administration: Prüfungen getrennt durchführen

Beim Xcode-Cloud-Zugriff auf ein Git-Repository sind mindestens zwei Fragen auseinanderzuhalten: Erreicht die Verbindung das Repository über die vorgesehenen Netzwerkregeln, und darf die von Xcode Cloud verwendete Verbindung auf das erforderliche Repository zugreifen? Die erste Frage prüfen Netzwerkverantwortliche. Die zweite gehört zur Administration der Quellcodeverwaltung und der dort hinterlegten Zugriffsrechte.

Bei einem selbst gehosteten Git-Dienst ist zunächst zu bestimmen, welche Stelle die eingehende Verbindung einschränkt. Prüfen Sie, ob die IP-Beschränkung unmittelbar am Dienst, in einer vorgeschalteten Firewall oder in einer weiteren Netzwerkkomponente durchgesetzt wird. Vergleichen Sie dann die dort wirksamen Regeln mit den offiziellen Xcode-Cloud-Bereichen. Wenn mehrere Ebenen Regeln enthalten, dokumentieren Sie, welche Ebene geändert wurde und welche weitere Prüfung aussteht.

Bei einem verwalteten Repository-Dienst kontrollieren Sie die dort konfigurierten Netzwerkbeschränkungen und die für das Repository verwendete Verbindung. Eine Dokumentation zu IP-Allowlists für Unternehmenszugriffe zeigt, dass solche Beschränkungen eigenständige Verwaltungseinstellungen sein können. Übertragen Sie Regeln oder Bedienungsdetails daraus nicht ungeprüft auf einen anderen Dienst; maßgeblich sind dessen eigene Einstellungen und die Richtlinien Ihres Unternehmens.

Prüfen Sie außerdem die Verbindung, die Xcode Cloud zur Quellcodeverwaltung verwendet, und vergewissern Sie sich, dass die nötigen Repository-Rechte weiterhin vorhanden sind. Wenn Sie nur die IP-Liste ändern, können abgelaufene Zugangsdaten, fehlende Berechtigungen oder eine falsche Repository-Zuordnung bestehen bleiben. Ändern Sie Berechtigungen nicht vorsorglich breiter als nötig, nur um einen Netzwerkfehler auszuschließen.

Häufige Fragen zur Prüfung im Team

Woher beziehen Sie die Ausgangs-IP-Bereiche?
Nutzen Sie Apples aktuelle Dokumentation zur Projekteinstellung für Xcode Cloud und vergleichen Sie sie mit den Xcode-Cloud-Veröffentlichungshinweisen. Prüfen Sie die dort aufgeführten Bereiche bei jeder Regeländerung erneut. Interne Kopien können für den Vergleich und die Änderungsdokumentation nützlich sein, sollten aber nicht als dauerhafte, von Apple unabhängige Quelle behandelt werden.

Welche Firewall-Regeln müssen nach einer Änderung erneut betrachtet werden?
Prüfen Sie vor allem die Regelobjekte, die den Repository-Zugriff begrenzen: an der Firewall, am Gateway und, falls vorhanden, an der Repository-Plattform. Verifizieren Sie, dass Quelle, Ziel und Protokoll dem genehmigten Zugriff entsprechen. Nehmen Sie keine Änderungen an nicht betroffenen Verbindungen vor, solange ein entsprechender Zusammenhang nicht durch Ihre Konfiguration und Tests belegt ist.

Was ist bei einem selbst gehosteten Repository zu tun?
Ermitteln Sie zuerst, an welcher Stelle der Zugriff gefiltert wird, und gleichen Sie dort die Freigaben mit Apples aktueller offizieller Dokumentation ab. Prüfen Sie anschließend die Repository-Verbindung und ihre Berechtigungen separat. Das Öffnen einer Netzwerkverbindung weist nicht nach, dass die verwendete Identität authentifiziert ist oder auf den benötigten Quellcode zugreifen darf.

Wie lässt sich ein erfolgreicher Zugriff nachweisen?
Führen Sie einen repräsentativen Workflow aus, der das betroffene Repository tatsächlich verwendet. Prüfen Sie den dokumentierten Lauf, die Verbindung und den erwarteten Build-Ablauf. Halten Sie Workflow und Ergebnis nachvollziehbar fest. Schlägt der Lauf fehl, untersuchen Sie Regelverteilung, Repository-Rechte und Workflow-Einstellungen unabhängig voneinander.

CI/CD-Verantwortliche: Funktion mit einem Workflow nachweisen

Ein erfolgreicher Eintrag in der Firewall-Konsole reicht als Abnahme nicht aus. Wählen Sie einen repräsentativen Xcode-Cloud-Workflow, der das betroffene Repository und den relevanten Zugriffspfad verwendet. Apples Anleitung zum Konfigurieren eines ersten Xcode-Cloud-Workflows beschreibt die Einrichtung eines Workflows. Für die Prüfung sollten Sie sich an einem realen Ablauf orientieren, den Ihr Team ohnehin für diesen Code verwendet.

Kontrollieren Sie zunächst, ob der Workflow die erwartete Repository-Verbindung nutzt und ob er das vorgesehene Projekt beziehungsweise den erwarteten Quellcode abruft. Verfolgen Sie anschließend den Lauf bis zum Build-Ergebnis. Die Dokumentation zu Workflow-Aktionen kann Ihnen helfen, die Aktionen des Workflows einzuordnen. Bewerten Sie jedoch nur die Ergebnisse, die Ihr konkreter Lauf tatsächlich liefert.

Bewahren Sie die Ausführungsprotokolle zusammen mit dem Änderungsnachweis auf. Ein erfolgreicher Lauf belegt, dass der geprüfte Workflow unter den getesteten Bedingungen funktioniert hat; er beweist nicht automatisch, dass jede andere Verbindung, jedes Repository oder jede Regelkonstellation ebenfalls korrekt ist. Umgekehrt reicht ein fehlgeschlagener Einzeltest nicht aus, um die IP-Bereiche als Ursache festzulegen.

Gehen Sie bei einem Fehlschlag in einer nachvollziehbaren Reihenfolge vor: Prüfen Sie zuerst, ob die geänderte Regel an der richtigen Stelle und mit dem genehmigten Inhalt wirksam ist. Bestätigen Sie danach die Repository-Verbindung, Authentifizierung und Zugriffsrechte. Kontrollieren Sie zuletzt, ob der Workflow die erwartete Konfiguration und das richtige Repository verwendet. Diese Trennung verhindert, dass eine fehlende Berechtigung durch eine unnötig breite Netzwerkfreigabe kaschiert wird.

Änderungsabschluss revisionsfähig dokumentieren

Führen Sie die entscheidenden Nachweise an einem Ort zusammen: die verwendete Apple-Quelle, den Zeitpunkt der Prüfung, die betroffenen Regelobjekte, den Änderungsantrag, die Genehmigung und das Ergebnis des repräsentativen Workflows. Ergänzen Sie die zuständige Rolle für eine spätere Quellenprüfung und die Person oder Funktion, die im Fehlerfall eine Rücknahme veranlassen darf. So bleibt sichtbar, welche Aussage aus Apple-Dokumentation stammt und welche Beobachtung Ihr eigenes Team gemacht hat.

Legen Sie außerdem fest, wer die Apple-Veröffentlichungshinweise und die Projektdokumentation künftig überprüft. Eine Regel ist nicht deshalb dauerhaft aktuell, weil sie nach einer früheren Änderung funktioniert hat. Wenn Apple die Bereiche, die Projekthinweise oder die Anforderungen für Repository-Zugriffe erneut ändert, sollte Ihre Organisation die Quelle erneut prüfen und entscheiden, ob eine neue Genehmigung oder ein weiterer Workflow-Test erforderlich ist.

Wenn Sie nach der Netzwerkprüfung zusätzlich eine macOS-Ausführungsumgebung für eigene Build-Aufgaben bewerten, vergleichen Sie zunächst die Betriebsmodelle und den tatsächlichen Bedarf Ihres Teams. Lokal beschaffte Macs binden Kapital und erfordern Pflege; gemeinsam genutzte interne Hardware setzt voraus, dass Sie Betrieb und Zugriffsverwaltung selbst übernehmen; allgemeine CI-Lösungen können macOS-spezifische Anforderungen nicht automatisch erfüllen. Keines dieser Modelle ist für jedes Unternehmen ungeeignet, aber jedes bringt andere laufende Aufgaben mit sich.

Für zeitlich begrenzte Tests oder zusätzliche macOS-Build-Kapazität kann ein gemieteter Mac eine passendere Alternative zum Kauf und zur internen Wartung sein. OakVM bietet den Zugriff auf reale, im Rechenzentrum gehostete Macs über VNC, SSH oder eine Webkonsole; prüfen Sie vor einer Entscheidung, ob dieses Betriebsmodell zu Ihren Anforderungen an Zugriff, Beschaffung und Verantwortlichkeiten passt. Einen Überblick zur Bewertung verschiedener Mac-Modelle finden Sie im Vergleich der Mac-Angebote. Wenn Sie offene Anforderungen zur Beschaffung klären möchten, können Sie außerdem über die Kontaktseite von OakVM nachfragen; die Eignung für Ihre Sicherheits- und Netzwerkregeln müssen Sie weiterhin anhand Ihrer eigenen Vorgaben bewerten.

Häufig gestellte Fragen