Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Zusätzliche Leitplanken
Wenn vorab signierte Anfragen von Lösungsentwicklern und Benutzern angemessen verwendet werden, bieten sie einen sicheren Mechanismus, um Benutzern Zugriff auf Daten zu gewähren. Darüber hinaus bietet die Möglichkeit, vorab signierte Anfragen zu generieren, den Prinzipalen keinen Zugriff, den sie nicht bereits hatten.
Sind in diesem Zusammenhang zusätzliche Kontrollen erforderlich? Zusätzliche Kontrollen werden nicht mit der Notwendigkeit gerechtfertigt, den Zugriff zu verweigern, sondern mit der Möglichkeit, die Nutzung zu überwachen, zu genehmigen und Grenzen festzulegen und das Risiko von Benutzerfehlern zu verringern. Auf diese Weise können Sie sicherstellen, dass die Nutzung angemessen und notwendig ist.
Die folgenden Leitplanken unterstützen Sie bei diesem Ziel. Bevor Sie diese Steuerelemente aktivieren, sollten Sie die aktuelle Nutzung ermitteln, indem Sie vorab signierte Anfragen identifizieren. Diese Identifizierung hilft Ihnen, sich auf die Auswirkungen der Leitplanke auf die bestehende Nutzung vorzubereiten oder bei Bedarf Ausnahmen zu planen.
Leitplanke für S3: Signature Age
Ein entscheidendes Merkmal vorsignierter Anfragen ist, dass sie eine Ablaufzeit beschreiben. Die Signatur der Anfrage enthält ein Datum. Dieses Datum wird als X-Amz-Date Abfragezeichenfolgenparameter für einen vorsignierten URLs und als Datum oder x-amz-date Header für einen vorsignierten POST übertragen.
Amazon S3 stellt einen Bedingungsschlüssel, s3:SignatureAge, zur Verfügung, mit dem Sie die maximale Zeit zwischen dem Datum der Unterzeichnung und dem effektiven Ablauf der Anfrage begrenzen können. Diese Bedingung kann die Gültigkeitsdauer niemals verlängern, aber sie kann sie verkürzen.
In der folgenden Richtlinie begrenzt der s3:signatureAge Bedingungsschlüssel die Gültigkeitsdauer vorab signierter Anfragen auf 15 Minuten. Die folgenden Beispiele verwenden alle 15 Minuten, um die Gültigkeit auf einen ähnlichen Zeitraum zu beschränken, wie es die Standardsignatur unterstützt.
Die zweite Aussage der Richtlinie verweigert jeglichen Zugriff auf Signature Version 2. Diese Version des Signaturprotokolls ist veraltet, wird aber von einigen noch unterstützt. AWS-Regionen Wir empfehlen, dass Sie es explizit blockieren, bevor es vollständig veraltet ist.
Sie können die folgende Richtlinie als AWS Organizations Service Control Policy (SCP) anwenden. Benutzer können weiterhin vorsignierte Anfragen verwenden und Lösungen bereitstellen, die von diesen Anforderungen abhängen, sofern zwischen der Generierung und Verwendung der Signatur weniger als 15 Minuten liegen. Je nach Implementierung hat diese Einschränkung möglicherweise keine Auswirkungen, sie kann dazu führen, dass die Lösung unbrauchbar wird, oder sie kann gelegentlich zu Fehlern führen, die erneut versucht werden können.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" } } }, { "Sid": "DenySignatureVersion2", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringEquals": { "s3:signatureversion": "AWS" } } } ] }
Ausnahmen
Wenn eine Lösung länger dauert, bis sie abläuft und sie daher von der oben genannten Richtlinie betroffen ist, empfehlen wir Ihnen, eine Methode zur Genehmigung von Ausnahmen bereitzustellen. Um zu vermeiden, dass Ausnahmen in einem SCP aufgezählt werden, verwenden Sie aws: PrincipalTag, wie in der folgenden Richtlinie, um Ausnahmen auf skalierbare Weise zu verwalten. Andere AWS Beispiele, wie z. B. die AWS-Datenperimeter-Richtlinien
Wenn Sie eine Ausnahmerichtlinie mithilfe von implementierenaws:PrincipalTag, müssen Sie den Zugriff auf Einstellungs-Tags für Prinzipale kontrollieren. Tags dieses Typs können direkt von Prinzipalen stammen und von einem SCP gesteuert werden, wie in diesem Beispiel zur Steuerung, welche Tag-Werte festgelegt werden könnenaws:PrincipalTag ist ein komplexes Thema. Ein Unternehmen, das Erfahrung mit der Verwendung der attributebasierten Zugriffskontrolle (ABAC) hat, wird jedoch über die nötige Erfahrung und Kontrolle verfügen, um die aws:PrincipalTag für diesen Anwendungsfall geeignete Verwendung von zu ermöglichen.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, --- Example exception --- "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } --- Example exception end --- } } ] }
Bucket-Richtlinien
Sie können Bucket-Richtlinien auf alle oder ausgewählte Buckets anwenden, indem Sie eine Richtlinie wie im folgenden Beispiel verwenden. Im Gegensatz zu einem SCP zielt eine Bucket-Richtlinie auch auf die Nutzung des Serviceprinzipals ab. Anhang A dokumentiert nicht die erwartete Nutzung von vorab signierten Anfragen durch den Serviceprinzipal. Wenn Sie jedoch eine Kontrolle implementieren möchten, um diese Grenze nachzuweisen, bietet die folgende Richtlinie diese Kontrolle. Im Gegensatz zu einem SCP kann eine Bucket-Richtlinie auch für Prinzipale in Ihrem Verwaltungskonto gelten. ABAC-basierte Ausnahmen funktionieren in Bucket-Richtlinien genauso wie SCP.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, --- Example exception --- "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } --- Example exception end --- } } ] }
Leitplanke für S3:AuthType
Vorsignierte URLs verwenden die Authentifizierung mit Abfragezeichenfolgen, und vorsignierte verwenden immer die POST-Authentifizierung. POSTs Amazon S3 unterstützt die Ablehnung von Anfragen auf der Grundlage des Authentifizierungstyps über den Bedingungsschlüssel s3:AuthType. REST-QUERY-STRINGist der s3:authType Wert für Abfragezeichenfolgen und POST ist der s3:authType Wert für POST.
Sie können die folgende Richtlinie als SCP anwenden. Die Richtlinie erlaubt nur s3:authType die Header-basierte Authentifizierung. Außerdem wird eine Methode konfiguriert, um Ausnahmen für einzelne Benutzer oder Rollen bereitzustellen.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] }
Das Ablehnen von Anfragen auf der Grundlage des Authentifizierungstyps wirkt sich auf alle Lösungen oder Funktionen aus, die den verweigerten Authentifizierungstyp verwenden. Durch das Ablehnen werden Benutzer beispielsweise REST-QUERY-STRING daran gehindert, Uploads oder Downloads von der Amazon S3 S3-Konsole aus durchzuführen. Wenn Sie möchten, dass Benutzer die Amazon S3 S3-Konsole verwenden, verwenden Sie diese Leitplanke nicht und machen Sie keine Ausnahme für Benutzer. Wenn Sie jedoch nicht möchten, dass Benutzer die Amazon S3 S3-Konsole verwenden, können Sie dies REST-QUERY-STRING für Benutzer verweigern.
Vielleicht verweigern Sie Benutzern bereits den direkten Zugriff auf Amazon S3 S3-Ressourcen. In diesem Fall ist eine Leitplanke für den Authentifizierungstyp überflüssig. Eine s3:authType defense-in-depth Deny-Anweisung ist jedoch nützlich, da Implementierungen zur Verweigerung des direkten Zugriffs in der Regel viele Steueranweisungen umfassen, von denen einige Ausnahmen enthalten.
Rollen, die für Workloads verwendet werden, benötigen normalerweise keinen Zugriff auf die Abfragezeichenfolge oder POST Authentifizierung. Ausnahmen sind Rollen, die Dienste unterstützen, die für die Verwendung vorsignierter Anfragen konzipiert sind. Sie können spezielle Ausnahmen für diese Rollen erstellen.
Sie können eine Bucket-Richtlinie auch auf alle oder ausgewählte Buckets anwenden, indem Sie eine Richtlinie wie die folgende verwenden:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] }
Diese Bucket-Richtlinie hat zur Folge, dass die Verwendung von CopyObjectund UploadPartCopy APIs zum Erstellen regionsübergreifender Kopien verweigert wird. Amazon S3 Replication ist nicht betroffen, da es sich nicht auf diese stützt APIs.
Wenn Sie eine Bucket-Richtlinie wie die vorherige Richtlinie verwenden und trotzdem die regionsübergreifende Richtlinie CopyObjectoder UploadPartCopyAPI unterstützen möchten, fügen Sie eine Bedingung hinzu, die der folgenden aws:ViaAWSService ähnelt:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" }, "Bool": { "aws:ViaAWSService": "false" }, } } ] }
Kombination von vordefinierten Leitplanken und Ausnahmen zu anderen Leitplanken
Wenn Sie nicht planen, eine Guardrail generell auf Ihre Benutzer und Rollen anzuwenden, sollten Sie sie vielleicht auf die Ausnahmen anderer gängiger Guardrails anwenden, sodass diese Ausnahmen keine vorsignierten Anfragen unterstützen.
Wenn Sie Netzwerkeinschränkungen haben, aber Ausnahmen für externe Partner oder spezielle Anwendungsfälle zulassen, sollten Sie die Abfragezeichenfolge oder die POST Authentifizierung blockieren, wenn diese Ausnahmen angewendet werden, sofern sie nicht ausdrücklich als erforderlich gekennzeichnet sind.
Einschränkungen für S3: SignatureAge
Administratoren werden es nützlich finden, die Auswirkungen von genauer zu verstehen. s3:signatureAge Jede signierte Anfrage enthältX-Amz-Date, was die aktuelle Uhrzeit angeben sollte. Dieser Wert wird vom Client und vom Unterzeichner der Anfrage eingegeben. AWS lehnt Anfragen ab, von denen er annimmt, dass sie ungültige Zeiten haben. Ein Unterzeichner könnte jedoch Signaturen im Voraus mit einem future Zeitpunkt generieren. Amazon S3 lehnt Anfragen ab, die eine future Uhrzeit angeben, wenn sie zu weit im Voraus gesendet wurden. Wenn die Anfrage jedoch erst zu dem Zeitpunkt gesendet wird, zu dem die Signatur unterzeichnet wurde, kann die Signatur früher generiert und später gesendet werden.
s3:signatureAgeschränkt das maximale Alter von X-Amz-Date in einer Signatur nur für vorab signierte Anfragen ein. Anfragen, die älter als das angegebene Alter sind, werden abgelehnt, auch wenn sie aufgrund des X-Amz-Expires Ablaufs oder einer POST Richtlinie für gültig erklärt worden wären. s3:signatureAgeändert nicht den Gültigkeitszeitraum für Anfragen, die kein explizites Ablaufdatum enthalten. Es kontrolliert auch nicht den WertX-Amz-Date, den ein Client für eine Signatur verwendet.
Wenn die Systemuhr falsch ist oder wenn ein Client Anfragen absichtlich in die Zukunft datiert, entspricht die signierte Zeit möglicherweise nicht der Zeit, zu der die Signatur generiert wurde. Das schränkt die Möglichkeiten eins3:signatureAge, Lösungen zu kontrollieren. Eine Lösung, die bei der Generierung von Signaturen die aktuelle Uhrzeit verwendet, ist erwartungsgemäß eingeschränkt: Die Signaturen bleiben für die in angegebene Anzahl von Millisekunden gültig. s3:signatureAge Für eine Lösung, die die aktuelle Zeit nicht verwendet, gelten andere Grenzwerte. Eine Einschränkung besteht darin, dass die Anmeldeinformationen, die zum Signieren der Signatur verwendet wurden, weiterhin gültig sein müssen. Als Administrator können Sie die maximale Gültigkeit der ausgegebenen temporären Anmeldeinformationen kontrollieren. Sie können festlegen, dass die Anmeldeinformationen bis zu 36 Stunden gültig sind, oder die Gültigkeitsdauer auf 15 Minuten beschränken. Der Ablauf temporärer Anmeldeinformationen hängt nicht vom Wert von abX-Amz-Date.
Für permanente Anmeldeinformationen gilt diese Einschränkung nicht. Es hat sich bewährt, nur temporäre Anmeldeinformationen zu verwenden, und Sie können alle permanenten Anmeldeinformationen explizit widerrufen, wodurch auch alle Signaturen, die auf diesen Anmeldeinformationen basieren, ungültig werden würden.
Es s3:signatureAge wird zwar in Millisekunden gemessen, es ist jedoch nicht praktikabel, es auf weniger als 60 Sekunden einzustellen, selbst wenn Sie eine gut synchronisierte Uhr und eine geringe Latenz haben. Bei Einstellungen unter 60 Sekunden besteht das Risiko, dass gültige Anfragen abgelehnt werden. Wenn Sie mit Verzögerungen zwischen der Signaturgenerierung und dem Einreichen der Anfrage oder mit Problemen bei der Uhrsynchronisierung rechnen, sollten Sie diese bei der Verwaltung von s3:signatureAge berücksichtigen.
Maßstabsgetreue Ausrichtung von Buckets
SCPs kann verwendet werdenaws:PrincipalTag, um Ausnahmen für Benutzer zu machen. Sie können in einem Bucket keine Tags verwenden, um den Zugriff zu kontrollieren aws:ResourceTag — nur Objekt-Tags werden für die Zugriffskontrolle verwendet. Es ist generell nicht skalierbar, jedem Objekt, auf das Sie diese Steuerung anwenden möchten, ein Tag hinzuzufügen.
Eine Lösung, die für viele Anwendungsfälle geeignet ist, besteht darin, die Richtlinie und die Ausnahme auf Kontoebene anzuwenden, indem entweder die Konten geändert werden, für die der SCP gilt, oder indem aws: ResourceAccount, aws: ResourceOrgPaths oder aws: ResourceOrg ID verwendet wird. Beispielsweise kann ein SCP auf eine Reihe von Produktionskonten angewendet werden.
Eine andere Lösung besteht darin, eine benutzerdefinierte AWS Config Regel zu verwenden, um eine detektive Kontrolle oder eine reaktionsschnelle Kontrolle zu implementieren. Das Ziel wäre, dass jeder Bucket eine Bucket-Richtlinie mit der entsprechenden Leitplanke enthält. Zusätzlich zum Testen des Inhalts einer Bucket-Richtlinie kann die benutzerdefinierte AWS Config Regel die Tags aus dem Bucket abrufen und den Bucket von der Regel ausschließen, wenn der Bucket mit einem bestimmten Wert gekennzeichnet ist. Wenn diese Regel ihre Konformitätsprüfung nicht besteht, könnte sie entweder den Bucket als nicht konform markieren oder eine Problembehebung einleiten, um die Guardrail zur Richtlinie des Buckets hinzuzufügen.
Anmerkung
Sie können den Tag-Inhalt von Anfragen nicht auf beschränken. PutBucketTagging Um die Kontrolle darüber zu behalten, wie ein Bucket gekennzeichnet wird, müssen Sie den Zugriff auf PutBucketTagging und einschränken DeleteBucketTagging.
