기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
추가 가드레일
솔루션 빌더와 사용자가 미리 서명된 요청을 적절하게 사용하면 사용자에게 데이터에 대한 액세스 권한을 부여하는 안전한 메커니즘을 제공합니다. 또한 미리 서명된 요청을 생성할 수 있다고 해서 보안 주체가 아직 가지고 있지 않은 액세스 권한을 제공하지는 않습니다.
이러한 맥락에서 추가 제어가 필요합니까? 추가 제어의 근거는 액세스를 거부해야 할 필요가 아니라 모니터링, 사용량 승인 및 경계 설정, 사용자 오류로 인한 위험 감소 기능을 제공하는 것입니다. 이렇게 하면 사용이 적절하고 필요한지 확인할 수 있습니다.
다음 가드레일이이 목표에 도움이 됩니다. 이러한 제어를 활성화하기 전에 미리 서명된 요청을 식별하여 기존 사용량을 확인할 수 있습니다. 이 식별은 가드레일이 기존 사용에 미치는 영향을 준비하거나 필요한 경우 예외를 계획하는 데 도움이 됩니다.
s3:signatureAge용 가드레일
미리 서명된 요청의 한 가지 정의 특성은 만료 시간을 설명하는 것입니다. 요청에 대한 서명에는 날짜가 포함됩니다. 이 날짜는 미리 서명된 URLs의 X-Amz-Date 쿼리 문자열 파라미터로 전송되고 미리 서명된 POST의 날짜 또는 x-amz-date 헤더로 전송됩니다.
Amazon S3는 조건 키 s3:signatureAge를 제공합니다.이 키를 사용하여 서명된 날짜와 요청의 유효 만료 사이의 최대 시간을 제한할 수 있습니다. 이 조건은 유효 기간을 늘릴 수는 없지만 줄일 수는 있습니다.
다음 정책에서 s3:signatureAge 조건 키는 미리 서명된 요청을 15분의 유효성으로 제한합니다. 다음 예제에서는 모두 15분을 사용하여 표준 서명이 지원하는 것과 유사한 기간으로 유효성을 제한합니다.
정책의 두 번째 문은 서명 버전 2 액세스를 거부합니다. 이 버전의 서명 프로토콜은 더 이상 사용되지 않지만 일부 에서는 여전히 지원됩니다 AWS 리전. 완전히 사용 중단되기 전에 명시적으로 차단하는 것이 좋습니다.
다음 정책을 AWS Organizations 서비스 제어 정책(SCP)으로 적용할 수 있습니다. 사용자는 서명 생성과 사용 사이의 시간이 15분 미만인 한 미리 서명된 요청을 사용하고 이러한 요청에 의존하는 솔루션을 배포할 수 있습니다. 구현에 따라이 제한은 영향을 미치지 않거나, 솔루션을 사용할 수 없게 되거나, 때때로 재시도할 수 있는 장애가 발생할 수 있습니다.
{ "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" } } } ] }
예외
솔루션이 만료되기 전에 더 오랜 시간이 필요하여 이전 정책의 영향을 받는 경우 예외를 승인하는 방법을 제공하는 것이 좋습니다. SCP에서 예외가 열거되지 않도록 하려면 다음 정책과 같이 aws:PrincipalTag를 사용하여 확장 가능한 방식으로 예외를 관리합니다. AWS 데이터 경계 정책 AWS 예제와 같은 다른 예제에서는이 전략을 사용합니다. https://github.com/aws-samples/data-perimeter-policy-examples/blob/main/README.md#tagging-conventions
를 사용하여 예외 정책을 구현하는 경우 aws:PrincipalTag보안 주체에 대한 태그 설정에 대한 액세스를 제어해야 합니다. 이 유형의 태그는 보안 주체에서 직접 가져올 수 있으며 설정할 수 있는 태그 값을 제어하는이 예제와 같이 SCP에서 제어할 수 있습니다aws:PrincipalTag 것은 복잡한 주제입니다. 그러나 속성 기반 액세스 제어(ABAC)를 사용한 경험이 있는 조직은이 사용 사례에 aws:PrincipalTag 대해를 적절하게 사용할 수 있는 경험과 제어를 갖게 됩니다.
{ "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 --- } } ] }
버킷 정책
다음 예제와 같이 정책을 사용하여 모든 버킷 또는 선택한 버킷에 버킷 정책을 적용할 수 있습니다. SCP와 달리 버킷 정책은 서비스 보안 주체 사용량도 대상으로 합니다. 부록 A는 미리 서명된 요청의 예상 서비스 보안 주체 사용량을 문서화하지 않지만, 해당 제한을 증명하기 위해 제어를 구현하려는 경우 다음 정책이 해당 제어를 제공합니다. 또한 SCP와 달리 버킷 정책은 관리 계정의 보안 주체에게 적용될 수 있습니다. ABAC 기반 예외는 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 --- } } ] }
s3:authType용 가드레일
미리 서명된 URLs 쿼리 문자열 인증을 사용하고 미리 서명된 POSTs 항상 POST 인증을 사용합니다. Amazon S3는 s3:authType 조건 키를 통해 인증 유형에 따른 요청 거부를 지원합니다. REST-QUERY-STRING는 쿼리 문자열의 s3:authType 값이고 POST는 POST의 s3:authType 값입니다.
다음 정책을 SCP로 적용할 수 있습니다. 이 정책은 s3:authType를 사용하여 헤더 기반 인증만 허용합니다. 또한 개별 사용자 또는 역할에 예외를 제공하도록 메서드를 구성합니다.
{ "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" } } } ] }
인증 유형을 기반으로 요청을 거부하면 거부된 인증 유형을 사용하는 모든 솔루션 또는 기능에 영향을 미칩니다. 예를 들어 거부하면 사용자가 Amazon S3 콘솔에서 업로드 또는 다운로드를 수행할 수 REST-QUERY-STRING 없습니다. 사용자가 Amazon S3 콘솔을 사용하도록 하려면이 가드레일을 사용하지 않거나 사용자에 대해 예외를 적용합니다. 반면 사용자가 Amazon S3 콘솔을 사용하지 않도록 하려면 REST-QUERY-STRING 사용자를 거부할 수 있습니다.
Amazon S3 리소스에 대한 사용자의 직접 액세스를 이미 거부했을 수 있습니다. 이 경우 인증 유형에 대한 가드레일은 중복됩니다. 그러나 직접 액세스를 s3:authType 거부하는 구현은 일반적으로 많은 제어 명령문에 걸쳐 있으며 일부는 예외가 있기 때문에 거부 명령문은 defense-in-depth 유틸리티를 제공합니다.
워크로드에 사용되는 역할은 일반적으로 쿼리 문자열 또는 POST 인증에 액세스할 필요가 없습니다. 예외는 미리 서명된 요청을 사용하도록 설계된 서비스를 지원하는 역할입니다. 이러한 역할에 대한 특정 예외를 생성할 수 있습니다.
다음과 같은 정책을 사용하여 모든 버킷 또는 선택한 버킷에 버킷 정책을 적용할 수도 있습니다.
{ "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" } } } ] }
이 버킷 정책은 CopyObject 및 UploadPartCopy APIs 것을 거부하는 효과가 있습니다. Amazon S3 복제는 이러한 APIs에 의존하지 않으므로 영향을 받지 않습니다.
이전 정책과 같은 버킷 정책을 사용하고 교차 리전 CopyObject 또는 UploadPartCopy API를 계속 지원하려면 다음과 aws:ViaAWSService 유사한에 대한 조건을 추가합니다.
{ "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" }, } } ] }
미리 서명된 가드레일 및 예외를 다른 가드레일에 결합
가드레일을 일반적으로 사용자 및 역할에 적용할 계획이 없는 경우 다른 일반적인 가드레일의 예외에 적용할 수 있으므로 이러한 예외는 미리 서명된 요청을 지원하지 않습니다.
네트워크 제한이 있지만 외부 파트너 또는 특수 사용 사례에 대한 예외를 허용하는 경우, 해당 예외가 적용될 때 쿼리 문자열 또는 POST 인증을 차단해야 합니다. 단, 이러한 예외가 필요한 것으로 특별히 식별되는 경우는 예외입니다.
s3:signatureAge에 대한 제한 사항
관리자는의 영향을 s3:signatureAge 더 완전히 이해하는 것이 유용할 것입니다. 서명된 모든 요청에는 현재 시간을 나타내야 X-Amz-Date하는가 포함됩니다. 이 값은 클라이언트에 의해 채워지며 요청 서명자는 유효하지 않은 시간이 있는 것으로 간주되는 요청을 AWS 거부합니다. 그러나 서명자는 나중에 서명을 미리 생성할 수 있습니다. Amazon S3는 미리 너무 많이 전송되는 경우 미래 시간을 지정하는 요청을 거부합니다. 그러나 서명에 로그인한 시간까지 요청이 전송되지 않는 경우 서명을 더 일찍 생성하고 나중에 전송할 수 있습니다.
s3:signatureAge는 미리 서명된 요청에 대해서만 서명X-Amz-Date의 최대 기간을 제한합니다. X-Amz-Expires 또는 POST 정책에서 만료가 유효하다고 선언했더라도 지정된 기간보다 오래된 요청은 거부됩니다.s3:signatureAge는 명시적 만료를 포함하지 않는 요청에 대한 유효 기간을 변경하지 않습니다. 또한 클라이언트X-Amz-Date가 서명에 사용하는의 값도 제어하지 않습니다.
시스템 클럭이 잘못되었거나 클라이언트가 의도적으로 미래 날짜를 요청하는 경우 서명이 생성된 시간이 서명 시간이 아닐 수 있습니다. 이렇게 하면 솔루션을 제어할 s3:signatureAge 수 있는 양이 제한됩니다. 서명을 생성할 때 현재 시간을 사용하는 솔루션은 예상대로 제한됩니다. 서명은에 지정된 밀리초 수 동안 유효합니다s3:signatureAge. 현재 시간을 사용하지 않는 솔루션은 다른 제한을 갖습니다. 한 가지 제한 사항은 서명에 사용된 자격 증명이 여전히 유효해야 한다는 것입니다. 관리자는 발급된 임시 자격 증명의 최대 유효성을 제어할 수 있습니다. 자격 증명이 최대 36시간 동안 유효하도록 허용하거나 유효성을 15분으로 제한할 수 있습니다. 임시 자격 증명의 만료는 값에 따라 달라지지 않습니다X-Amz-Date.
영구 자격 증명에는이 제한이 없습니다. 임시 자격 증명만 사용하는 것이 모범 사례이며 영구 자격 증명을 명시적으로 취소할 수 있습니다. 그러면 해당 자격 증명을 기반으로 하는 서명도 무효화됩니다.
s3:signatureAge는 밀리초 단위로 측정되지만, 동기화가 잘 되고 지연 시간이 짧은 클럭이 있더라도 60초 미만으로 설정하는 것은 실용적이지 않습니다. 60초 미만의 설정은 유효한 요청을 거부할 위험이 있습니다. 서명 생성과 요청 제출 사이에 지연이 예상되거나 클럭 동기화 문제가 발생하는 경우 관리에서 이를 고려해야 합니다s3:signatureAge.
대규모 버킷 대상 지정
SCPs aws:PrincipalTag를 사용하여 사용자에 대한 예외를 만들 수 있습니다. 버킷의 태그를 사용하여를 통해 액세스를 제어할 수 없습니다. aws:ResourceTag- 액세스 제어에는 객체 태그만 사용됩니다. 이 제어를 적용하려는 모든 객체에 태그를 추가하는 것은 일반적으로 확장 가능하지 않습니다.
많은 사용 사례에 적합한 솔루션은 SCP가 적용되는 계정을 변경하거나 aws:ResourceAccount, aws:ResourceOrgPaths 또는 aws:ResourceOrgID를 사용하여 계정 수준에서 정책 및 예외를 적용하는 것입니다. 예를 들어 SCP는 프로덕션 계정 집합에 적용될 수 있습니다.
또 다른 솔루션은 사용자 지정 AWS Config 규칙을 사용하여 탐지 제어 또는 대응 제어를 구현하는 것입니다. 목표는 모든 버킷에 적절한 가드레일이 있는 버킷 정책을 포함하는 것입니다. 버킷 정책의 내용을 테스트하는 것 외에도 사용자 지정 AWS Config 규칙은 버킷에서 태그를 검색하고 버킷에 특정 값으로 태그가 지정된 경우 규칙에서 버킷을 제외할 수 있습니다. 해당 규칙이 규정 준수 검사에 실패하면 버킷을 규정 미준수로 표시하거나 버킷 정책에 가드레일을 추가하기 위한 수정을 호출할 수 있습니다.
참고
요청의 태그 콘텐츠를 PutBucketTagging으로 제한할 수 없습니다. 버킷에 태그를 지정하는 방법을 제어하려면 PutBucketTagging 및 DeleteBucketTagging에 대한 액세스를 제한해야 합니다.
