AWS-JSON-Richtlinienelemente: Principal - AWS Identity and Access Management

AWS-JSON-Richtlinienelemente: Principal

Verwenden Sie das Principal-Element in einer ressourcebasierten JSON Richtlinie, um den Auftraggeber anzugeben, dem der Zugriff auf eine Ressource erlaubt oder verweigert wird.

Sie können das Principal-Element in ressourcenbasierten Richtlinien verwenden. Mehrere Services unterstützen ressourcenbasierte Richtlinien, einschließlich IAM. Der ressourcenbasierte IAM-Richtlinientyp ist eine Rollenvertrauensrichtlinie. Verwenden Sie in IAM-Rollen das Element Principal-Element in der Rollenvetrauensichtlinie, um anzugeben, wer diese Rolle annehmen kann. Für den kontoübergreifenden Zugriff müssen Sie die 12-stellige ID des vertrauenswürdigen Kontos angeben. Informationen darüber, ob Auftraggeber in Konten außerhalb Ihrer Vertrauenszone (vertrauenswürdige Organisation oder Konto) Zugriff zur Annahme Ihrer Rollen haben, finden Sie unter Was ist IAM Access Analyzer?.

Anmerkung

Nachdem Sie die Rolle erstellt haben, können Sie das Konto zu „*“ ändern, damit jeder die Rolle annehmen kann. Wenn Sie dies tun, empfehlen wir dringend, dass Sie den Zugriff auf die Rolle mit anderen Mitteln begrenzen, wie z. B. mit einem Condition-Element, das den Zugriff auf bestimmte IP-Adressen beschränkt. Schränken Sie den Zugriff auf Ihre Rolle unbedingt ein!

Andere Beispiele für Ressourcen, die ressourcenbasierte Richtlinien unterstützen, sind ein Amazon-S3-Bucket oder einen AWS KMS key.

Sie können das Element Principal nicht in einer identitätsbasierten Richtlinie verwenden. Identitätsbasierte Richtlinien sind Berechtigungsrichtlinien, die Sie an eine IAM-Identität anfügen können, wie z. B. -Benutzer, -Rollen oder -Gruppen. In diesen Richtlinien wird der Prinzipal von der Identität impliziert, der der Richtlinie angefügt ist.

Angeben eines Auftraggebers

Sie geben einen Prinzipal in dem Principal-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln an, die Prinzipale unterstützen. Sie können beispielsweise einen Prinzipal Amazon-Ressourcenname(ARN) im aws:PrincipalArn-Bedingungsschlüssel angeben.

Sie können einen der folgenden Auftraggeber in einer Richtlinie angeben:

  • AWS-Konto und -Stammbenutzer

  • IAM roles (IAM-Rollen)

  • Rollensitzungen

  • IAM-Benutzer

  • Verbundbenutzersitzungen

  • AWS-Services

  • Alle Prinzipale

Sie können mehrere Auftraggeber für jeden der Auftraggebertypen in den folgenden Abschnitten mithilfe eines Arrays angeben. Arrays können einen oder mehrere Werte enthalten. Wenn Sie mehr als einen Auftraggeber im Element angeben, erteilen Sie jedem Auftraggeber Berechtigungen. Dies ist ein logisches OR und kein logisches AND, da Sie jeweils als ein Auftraggeber authentifiziert sind. Wenn Sie mehr als einen Wert angeben, verwenden Sie eckige Klammern ([ und ]) und trennen Sie jeden Eintrag für das Array durch Kommas. Die folgende Beispielrichtlinie definiert Berechtigungen für das 123456789012-Konto oder das 555555555555-Konto.

"Principal" : { "AWS": [ "123456789012", "555555555555" ] }
Anmerkung

Sie können keinen Platzhalter verwenden, um einen Teil eines Namens oder eines ARNs zu ersetzen.

AWS-Kontoauftraggeber

Sie können AWS-Konto-Kennungen im Principal-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen. Dadurch wird die Autorität des Kontos delegiert. Wenn Sie den Zugriff auf ein anderes Konto zulassen, muss ein Administrator in diesem Konto dann Zugriff auf eine Identität (IAM-Benutzer oder -Rolle) in diesem Konto gewähren. Wenn Sie ein AWS-Konto angeben, können Sie den Konto-ARN (arn:aws:iam::account-ID:root) oder eine Kurzform verwenden, die aus dem "AWS":-Präfix, gefolgt von der Konto-ID, besteht.

Wenn die Konto-ID beispielsweise 123456789012 lautet, können Sie eine der folgenden Methoden verwenden, um das betreffende Konto im Element Principal anzugeben:

"Principal": { "AWS": "arn:aws:iam::123456789012:root" }
"Principal": { "AWS": "123456789012" }

Mit dem Konto-ARN und der verkürzten Konto-ID verhält es sich genauso. Beide delegieren Berechtigungen für das Konto. Wenn das Konto ARN im Principal-Element verwendet wird, werden die Berechtigungen nicht nur auf den Stamm-Benutzer des Kontos beschränkt.

Anmerkung

Wenn Sie eine ressourcenbasierte Richtlinie speichern, die die verkürzte Konto-ID enthält, konvertiert der Dienst sie möglicherweise in den Haupt-ARN. Dies ändert nichts an der Funktionalität der Richtlinie.

Einige AWS-Services unterstützen zusätzliche Optionen für die Angabe eines Kontoauftraggebers. Bei Amazon S3 können Sie beispielsweise eine kanonische Benutzer-ID in folgendem Format angeben:

"Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }

Sie können auch mehr als ein AWS-Konto angeben (oder kanonische Benutzer-ID) als Prinzipal, der ein Array verwendet. Beispielsweise können Sie mit allen drei Methoden einen Prinzipal in einer Bucket-Richtlinie angeben.

"Principal": { "AWS": [ "arn:aws:iam::123456789012:root", "999999999999", "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" ] }

IAM-Rollenauftraggeber

Sie können IAM-Rollenprinzipal-ARNs im Principal-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln, die Prinzipale unterstützen. IAM-Rollen sind Identitäten. In IAM sind Identitäten Ressourcen, denen Sie Berechtigungen zuweisen können. Rollen vertrauen einer anderen authentifizierten Identität, um diese Rolle zu übernehmen. Dies beinhaltet einen Prinzipal in AWS oder einem Benutzer eines externen Identitätsanbieters (IdP). Wenn ein Prinzipal oder eine Identität eine Rolle übernimmt, erhalten sie temporäre Sicherheitsanmeldeinformationen mit den Berechtigungen der angenommenen Rolle. Wenn sie diese Sitzungsanmeldeinformationen verwenden, um Vorgänge in AWS auszuführen, werden sie Rollensitzungsprinzipal.

IAM-Rollen sind Identitäten, die in IAM existieren. Rollen vertrauen einer anderen authentifizierten Identität, z. B. einem Prinzipal in AWS oder einem Benutzer eines externen Identitätsanbieters. Wenn ein Prinzipal oder eine Identität eine Rolle übernimmt, erhält er temporäre Sicherheitsanmeldeinformationen. Sie können diese Anmeldeinformationen dann als Rollensitzungsprinzipal verwenden, um Vorgänge in AWS durchzuführen.

Wenn Sie einen Rollenprinzipal in einer ressourcenbasierten Richtlinie angeben, sind die effektiven Berechtigungen für den Prinzipal durch alle Richtlinientypen begrenzt, die Berechtigungen für die Rolle einschränken. Dies umfasst Sitzungssrichtlinien und Berechtigungsgrenzen. Weitere Informationen zur Auswertung der effektiven Berechtigungen für eine Rollensitzung finden Sie unter Auswertungslogik für Richtlinien.

Um die Rolle ARN im Principal-Element anzugeben, verwenden Sie das folgende Format:

"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }
Wichtig

Wenn Ihr Principal-Element in einer Vertrauensrichtlinie einer Rolle einen ARN enthält, der auf eine bestimmte IAM-Rolle verweist, wird dieser ARN beim Speichern der Richtlinie in die eindeutige Auftraggeber-ID der Rolle umgewandelt. Auf diese Weise wird das Risiko reduziert, dass jemand seine Berechtigungen durch Entfernen und Neuerstellen der Rolle erweitert. Normalerweise wird diese ID nicht in der Konsole angezeigt, da bei der Anzeige der Vertrauensrichtlinie auch eine Rückumwandlung zum ARN erfolgt. Wenn Sie jedoch die Rolle löschen, wird die Beziehung aufgehoben. Die Richtlinie wird nicht mehr angewendet, selbst wenn Sie die Rolle neu erstellen, da die Auftraggeber-ID der neuen Rolle nicht mit der in der Vertrauensrichtlinie gespeicherten ID übereinstimmt. In diesem Fall wird die Auftraggeber-ID in der Konsole angezeigt, da AWS sie nicht mehr einem gültigen ARN zuordnen kann. Daher müssen Sie die Rolle bearbeiten, um die nunmehr falsche Auftraggeber-ID mit dem richtigen ARN zu ersetzen, wenn Sie eine mit einem Principal-Element einer Vertrauensrichtlinie verknüpfte Rolle löschen und neu erstellen. Der ARN wird beim Speichern der Richtlinie erneut in die neue Auftraggeber-ID der Rolle umgewandelt.

Alternativ können Sie den Rollenprinzipal als Prinzipal in einer ressourcenbasierten Richtlinie angeben oder erstellen Sie eine Richtlinie mit breiter Berechtigung die aws:PrincipalArn-Bedingungsschlüssel benutzt. Wenn Sie diesen Schlüssel verwenden, erteilen Sie dem Rollensitzungsprinzipalen die Berechtigungen basierend auf dem übernommenen ARN der Rolle und nicht dem ARN der resultierenden Sitzung. Da AWS-Bedingungsschlüssel-ARNs nicht in IDs konvertiert, bleiben die für die Rollen-ARN erteilten Berechtigungen bestehen, wenn Sie die Rolle löschen und dann eine neue Rolle mit demselben Namen erstellen. Berechtigungen, die mit dem aws:PrincipalArn-Bedingungsschlüssel erteilt wurden, sind nicht durch identitätsbasierte Richtlinientypen wie Berechtigungsgrenzen oder Sitzungsrichtlinien begrenzt.

Rollensitzungsgsprinzipale

Sie können Rollensitzungen im Principal-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln, die Prinzipale unterstützen, angeben. Wenn ein Prinzipal oder eine Identität eine Rolle übernimmt, erhalten sie temporäre Sicherheitsanmeldeinformationen mit den Berechtigungen der angenommenen Rolle. Wenn sie diese Sitzungsanmeldeinformationen verwenden, um Vorgänge in AWS durchzuführen, werden sie Rollensitzungsprinzipal.

Das Format, das Sie für einen Rollensitzungsprinzipal verwenden, hängt von der AWS STS-Produktion ab, die verwendet wurde, um die Rolle zu übernehmen.

Darüber hinaus können Administratoren einen Prozess entwerfen, um zu steuern, wie Rollensitzungen ausgegeben werden. Sie können beispielsweise eine Ein-Klick-Lösung für ihre Benutzer bereitstellen, die einen vorhersehbaren Sitzungsnamen erstellt. Wenn Ihr Administrator dies tut, können Sie Rollensitzungsprinzipale in Ihren Richtlinien oder Bedingungsschlüsseln verwenden. Andernfalls können Sie die Rolle ARN als Prinzipal oder im aws:PrincipalArn-Bedingungsschlüssel angeben. Wie Sie die Rolle als Prinzipal angeben, kann die effektiven Berechtigungen für die resultierend Sitzung ändern. Weitere Informationen finden Sie unter IAM-Rollenauftraggeber.

Sitzungsauftraggeber mit übernommener Rolle

Ein Prinzipal mit angenommener Rollensitzung ist ein Sitzungssprinzipal, der sich aus der Verwendung der AWS STS-AssumeRole-Produktion ergibt. Weitere Informationen darüber, welche Prinzipale bei dieser Operation eine Rolle übernehmen können, finden Sie unter Vergleichen der AWS STS-API-Operationen.

Um den ARN mit angenommener Rollensitzung im Principal-Element anzugeben, verwenden Sie das folgende Format:

"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }

Wenn Sie eine Sitzung mit übernommener Rolle in einem Principal-Element angeben, können Sie keinen Platzhalter „*“ verwenden, der "alle Sitzungen" bedeutet. Auftraggeber müssen immer eine bestimmte Sitzung benennen.

Prinzipale für Webidentitätssitzungen

Ein Prinzipal für Webidentitätssitzung ist ein Sitzungsprinzipal, der sich aus der Verwendung von AWS STS AssumeRoleWithWebIdentity ergibt. Sie können einen externen Web Identity Provider (IdP) verwenden, um sich anzumelden und dann mit diesem Vorgang eine IAM-Rolle übernehmen. Dies nutzt den Identitätsverbund und gibt eine Rollensitzung aus. Weitere Informationen darüber, welche Prinzipale bei dieser Produktion eine Rolle übernehmen können, finden Sie unter Vergleichen der AWS STS-API-Operationen.

Wenn Sie eine Rolle von einem Webidentitätsanbieter ausgeben, erhalten Sie diese spezielle Art von Sitzungsprinzipal, der Informationen über den Web-Identitätsanbieter enthält.

Verwenden Sie diesen Prinziptyp in Ihrer Richtlinie, um den Zugriff basierend auf dem vertrauenswürdigen Web-Identitätsanbieter zuzulassen oder abzulehnen. Um dem ARN der Web-Identitäts-Rollensitzung im Principal-Element eine Rollenvetrauensichtlinie zu geben, verwenden Sie das folgende Format:

"Principal": { "Federated": "cognito-identity.amazonaws.com" }
"Principal": { "Federated": "www.amazon.com" }
"Principal": { "Federated": "graph.facebook.com" }
"Principal": { "Federated": "accounts.google.com" }

SAML-Sitzungssprinzipale

Ein SAML-Sitzungsprinzipal ist ein Sitzungsprinzipal, der sich aus der Verwendung der AWS STS-AssumeRoleWithSAML-Produktion ergibt. Sie können sich mit einem externen SAML-Identitätsanbieter (IdP) anmelden und dann mit dieser Produktion eine IAM-Rolle übernehmen. Dies nutzt den Identitätsverbund und gibt eine Rollensitzung aus. Weitere Informationen darüber, welche Prinzipale bei dieser Produktion eine Rolle übernehmen können, finden Sie unter Vergleichen der AWS STS-API-Operationen.

Wenn Sie eine Rolle von einem SAML-Identitätsanbieter ausstellen, erhalten Sie diesen speziellen Typ von Vortrasprinzipal, der Informationen über den SAML-Identitätsanbieter enthält.

Verwenden Sie diesen Prinziptyp in Ihrer Richtlinie, um den Zugriff basierend auf dem vertrauenswürdigen SAML-Identitätsanbieter zuzulassen oder abzulehnen. Um den ARN der Web-Identitäts-Rollensitzung im Principal-Element einer Rollenvetrauensichtlinie anzugeben, verwenden Sie das folgende Format:

"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }

IAM-Benutzerprinzipal

Sie können den IAM-Benutzer im Principal-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen.

Anmerkung

Bei einem Principal-Element, bei dem Benutzernamen Teil des Amazon-Ressourcenname(ARN) ist, wird zwischen Groß- und Kleinschreibung unterschieden.

"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" }
"Principal": { "AWS": [ "arn:aws:iam::AWS-account-ID:user/user-name-1", "arn:aws:iam::AWS-account-ID:user/user-name-2" ] }

Wenn Sie Benutzer in einem Principal-Element angeben, können Sie keinen Platzhalter (*) für "alle Benutzer" verwenden. Auftraggeber müssen stets bestimmter Benutzer angeben.

Wichtig

Wenn Ihr Principal-Element in einer Rollenvetrauensichtlinie einen ARN enthält, der auf einen bestimmten IAM-Benutzer verweist, wird dieser ARN beim Speichern der Richtlinie in die eindeutige Auftraggeber-ID des Benutzers umgewandelt. Auf diese Weise wird das Risiko reduziert, dass jemand seine Berechtigungen durch Entfernen und Neuerstellen des Benutzers erweitert. Normalerweise wird diese ID nicht in der Konsole angezeigt, da bei der Anzeige der Vertrauensrichtlinie auch eine Rückumwandlung in die Benutzer-ARN erfolgt. Wenn Sie jedoch den Benutzer löschen, wird die Beziehung aufgehoben. Die Richtlinie wird dann nicht mehr angewendet, selbst wenn Sie den Benutzer neu erstellen. Dies liegt daran, dass die Auftraggeber-ID des neuen Benutzers nicht mit der in der Vertrauensrichtlinie gespeicherten ID übereinstimmt. In diesem Fall wird die Auftraggeber-ID in der Konsole angezeigt, da AWS sie nicht mehr einem gültigen ARN zuordnen kann. Daher müssen Sie die Rolle bearbeiten, um die nunmehr falsche Auftraggeber-ID durch den richtigen ARN zu ersetzen, wenn Sie einen mit einem Principal-Element einer Vertrauensrichtlinie verknüpften Benutzer löschen und neu erstellen. Der ARN wird beim Speichern der Richtlinie erneut in die neue Auftraggeber-ID des Benutzers umgewandelt.

AWS STS-Prinzipal für Verbundbenutzersitzungen

Sie können Verbundbenutzersitzungen im Principal-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen.

Wichtig

AWS empfiehlt die Verwendung von AWS STS Verbundbenutzersitzungen nur bei Bedarf, z. B. wenn Stammbenutzerzugriff erforderlich ist. Stattdessen, Verwenden von Rollen, um Berechtigungen zu delegieren.

Ein AWS STS-Prinzipal für Verbundbenutzersitzungen ist ein Sitzungssprinzipal, der sich aus der Verwendung des AWS STS GetFederationToken ergibt. In diesem Fall verwendet AWS STSIdentitätsverbund als Methode, um temporäre Zugriffstoken zu erhalten, anstatt IAM-Rollen zu verwenden.

In AWS, kann sich ein IAM-Benutzer oder ein AWS-Konto-Stammbenutzer mit langfristigen Zugriffsschlüsseln authentifizieren. Weitere Informationen zum Verbünden von Prinzipalen mittles dieser Produktion finden Sie unter Vergleichen der AWS STS-API-Operationen.

  • IAM-Verbundbenutzer - Ein IAM-Benutzer verbündet, mithilfe einer GetFederationToken-Produktion, die zu einem Prinzipal für Verbundbenutzersitzungen für diesen IAM-Benutzer führt.

  • Stamm-Verbundbenutzer - Ein Root-Benutzer verbündet mithilfe einer GetFederationToken-Produktion, die zu einem Prinzipal für Verbundbenutzer-Sitzungen für diesen Root-Benutzer führt.

Wenn ein IAM-Benutzer oder Stammbenutzer temporäre Anmeldeinformationen von AWS STS mit diesem Vorgang anfordert, beginnen sie eine temporäre Verbundbenutzersitzung. Der ARN dieser Sitzung basiert auf der ursprünglichen Identität, die verbunden wurde.

Um den ARN der Verbundbenutzersitzung im Principal-Element anzugeben, verwenden Sie das folgende Format:

"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" }

AWS-Dienstauftraggeber

Sie können AWS-Services im Principal-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen. Ein Service-Prinzipal ist eine Kennung für einen Service.

IAM-Rollen, die von einem AWS-Dienst übernommen werden können, werden als -Servicerollen bezeichnet. Service-Rollen müssen eine Vertrauensrichtlinie enthalten. Vertrauensrichtlinien sind ressourcenbasierte Richtlinien, die einer Rolle zugeordnet sind. Sie definiert, welche Auftraggeber die Rolle übernehmen können. Einige Service-Rollen haben vordefinierte Vertrauensrichtlinien. In einigen Fällen müssen Sie jedoch den Dienstauftraggeber in der Vertrauensrichtlinie angeben.

Der Bezeichner für einen Dienstauftraggeber enthält den Servicenamen und hat normalerweise das folgende Format:

service-name.amazonaws.com

Der Dienstauftraggeber wird durch den Service definiert. Sie können den Dienstauftraggeber für einige Services finden, indem Sie AWS-Services, die mit IAM funktionieren öffnen, überprüfen, ob der Service in der Spalte Service-linked role (Serviceverknüpfte Rolle) Yes (Ja) hat, und den Link Yes (Ja) öffnen, um die Dokumentation zu serviceverknüpften Rollen für diesen Service anzuzeigen. Suchen Sie den Abschnitt Service-Linked Role Permissions (Berechtigungen von serviceverknüpften Rollen) für diesen Service, um den Dienstauftraggeber anzuzeigen.

Das folgende Beispiel zeigt eine Richtlinie, die einer Service-Rolle angefügt werden kann. Diese Richtlinie ermöglicht zwei Services, Amazon ECS und Elastic Load Balancing, die Übernahme der Rolle. Die Services können dann sämtliche Aufgaben ausführen, zu denen die Rolle infolge der zugewiesenen Berechtigungsrichtlinie berechtigt ist (nicht dargestellt). Geben Sie zur Angabe von mehreren Dienstauftraggeber nicht zwei Service-Elemente an. Sie können nur ein Element angeben. Verwenden Sie stattdessen ein Array mit mehreren Dienstauftraggeber als Wert eines einzelnen Service-Elements.

"Principal": { "Service": [ "ecs.amazonaws.com", "elasticloadbalancing.amazonaws.com" ] }

Alle Prinzipale

Sie können ein Platzhalterzeichen (*) verwenden, um alle Prinzipale im Principal-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln, die Prinzipale zu unterstützen. Als bewährte Methode tun Sie dies nur mitConditionElement und ein Bedingungsschlüssel wieaws:PrincipalArnum diese breiten Berechtigungen einzuschränken.

Bei ressourcenbasierten Richtlinien, wie Amazon S3-Bucket-Richtlinien, gibt ein Platzhalter (*) im Auftraggeberlement alle Benutzer oder den öffentlichen Zugriff an. Beispielsweise können Sie eine der folgenden Methoden verwenden, um alle Prinzipale imPrincipalelement anzugeben:

"Principal": "*"
"Principal" : { "AWS" : "*" }

Benutzen von "Principal": "*" mit einem Allow-Effekt in einer ressourcenbasierten Richtlinie ermöglicht es jedem, auch wenn er nicht bei AWS angemeldet ist, auf Ihre Ressource zuzugreifen.

Benutzen von "Principal" : { "AWS" : "*" } mit einem Allow-Effekt in einer ressourcenbasierten Richtlinie ermöglicht jeden Stammbenutzer, IAM-Benutzer, angenommener Rollensitzung oder Verbundbenutzer in einem beliebigen Konto in der selben Partition auf Ihre Ressource zuzugreifen. Für IAM-Benutzer- und Rollenprinzipale in Ihrem Konto sind keine anderen Berechtigungen erforderlich. Für Prinzipale in anderen Konten müssen sie auch identitätsbasierte Berechtigungen in ihrem Konto haben, mit denen sie auf Ihre Ressource zugreifen können. Dies wird als kontenübergreifender Zugriff bezeichnet. Diese Methode erlaubt es nicht, Prinzipale für Webidentitätssitzungen, SAML-Sitzungsprinzipale oder Service-Prinzipale auf Ihre Ressource zuzugreifen.

Wichtig

Weil jeder ein AWSKonto erstellen kann, ist dieSicherheitsstufedieser beiden Methoden gleichwertig, obwohl sie unterschiedlich funktionieren.

Sie können keinen Platzhalter verwenden, um einen Teil eines Namens oder einen ARN zu ersetzen.

Weitere Informationen

Weitere Informationen finden Sie unter: