Amazon SCS-C02: 데이터 보호 및 S3 — 학습 가이드

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS Security Specialty SCS-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

S3 버킷 정책, 리소스 ARN 및 명시적 Deny

S3 버킷 정책은 자격 증명 기반 정책과 함께 평가되는 리소스 기반 JSON 문서입니다. 동작을 지배하는 두 가지 규칙이 있습니다. 첫째, 명시적 Deny는 항상 우선합니다. 즉, 아무리 많은 Allow 문이 있더라도 일치하는 Deny가 있으면 요청이 차단됩니다. 둘째, Resource 요소는 작업의 ARN 패턴과 정확히 일치해야 합니다. s3:ListBucket과 같은 버킷 수준 작업은 arn:aws:s3:::my-bucket에서 작동하고, s3:GetObject 및 s3:PutObject와 같은 객체 수준 작업은 arn:aws:s3:::my-bucket/*에서 작동합니다. 흔한 잘못된 구성은 /* 접미사 없이 arn:aws:s3:::my-bucket에 s3:GetObject를 부여하는 것입니다. API 호출은 객체 ARN을 대상으로 하지만 일치하는 문이 없으므로 요청은 기본적으로 거부됩니다.

다음 정책은 TLS가 아닌 모든 액세스를 거부하고 특정 역할에 대한 읽기 권한을 부여하며, 두 가지 ARN 형식을 모두 올바르게 사용합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::reports",
        "arn:aws:s3:::reports/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "AllowAnalyticsRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/Analytics" },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports/*"
    }
  ]
}

자주 빠지는 함정은 광범위한 Deny 이후에 나중에 Allow를 추가하여 예외를 ‘만들어내려는’ 시도입니다. 정책 문은 순서에 민감하지 않으며, IAM 평가 로직은 일치하는 거부 문이 발견되는 즉시 Deny를 반환합니다. 올바른 해결 방법은 허용 문을 아래에 추가하는 대신 NotPrincipal이나 Condition 등을 통해 Deny의 범위를 좁히는 것입니다.

수명 주기 규칙, 객체 만료 및 Vault Lock

S3 수명 주기 규칙은 스토리지 클래스 전환 및 객체 만료를 자동화합니다. 보존 요구 사항(예: 수집 후 30일이 지난 PII 제거)을 충족하려면, 현재 객체 버전을 30일 후에 만료시키고 그 직후에 현재가 아닌 버전을 영구적으로 삭제하는 규칙을 연결해야 합니다. DynamoDB에 기록된 관련 메타데이터의 경우, DynamoDB TTL 속성을 활성화하여 항목이 동일한 일정에 따라 자체 삭제되도록 합니다. 이 두 메커니즘을 결합하면 Lambda, 스케줄러 또는 맞춤형 정리 코드가 필요 없으므로 운영상 효율적입니다.

LifecycleConfiguration:
  Rules:
    - Id: ExpirePIIAfter30Days
      Status: Enabled
      Filter: { Prefix: "ingest/" }
      Expiration: { Days: 30 }
      NoncurrentVersionExpiration: { NoncurrentDays: 1 }

규제에 따른 보존이 필요한 아카이브 데이터의 경우, S3 Glacier Vault Lock은 볼트 수준에서 별도의 WORM 제어를 제공합니다. Vault Lock 정책이 커밋되면(24시간 이내에 시작/완료하는 2단계 프로세스), 계정 루트라도 이를 변경할 수 없습니다. 이는 S3 객체 수준에서 작동하는 Object Lock과는 다릅니다.

퍼블릭 액세스 차단 및 CloudFront OAC

**S3 퍼블릭 액세스 차단(BPA)**은 퍼블릭 액세스를 허용할 수 있는 모든 ACL이나 정책을 무시하는 계정 및 버킷 수준의 네 가지 스위치 집합입니다. 계정 수준에서 네 가지 모두를 활성화하고, 설정을 완화하는 s3:PutBucketPublicAccessBlock을 거부하는 등의 SCP로 이를 강제합니다. 이러한 심층 방어는 엔지니어가 허용적인 ACL을 통해 실수로 버킷을 다시 노출하는 것을 방지합니다.

CloudFront를 통해 제공되는 퍼블릭 콘텐츠의 경우, 올바른 패턴은 **Origin Access Control(OAC)**입니다. OAC는 SigV4를 사용하여 CloudFront에서 S3로의 요청에 서명합니다. 그러면 버킷 정책은 CloudFront 배포의 서비스 보안 주체만 허용합니다. OAC(또는 레거시 OAI) 없이 CloudFront에만 의존하면 S3 URL에 직접 액세스할 수 있게 되어 CDN의 액세스 제어 및 WAF가 무력화됩니다. 버킷은 비공개로 유지하고 BPA를 활성화해야 하며, 정책은 배포 ARN으로 범위를 지정해야 합니다.

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::site-assets/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCXYZ"
    }
  }
}

S3 Object Lock 및 교차 리전 복제

Object Lock은 개별 객체에 WORM 시맨틱을 적용하며, 버전 관리가 활성화되어 있고 버킷 생성 시 Object Lock이 켜져 있어야 합니다(기존 버킷에는 나중에 AWS에 문의하지 않고는 추가할 수 없습니다). 두 가지 보존 모드가 있습니다:

• 거버넌스 모드: s3:BypassGovernanceRetention 권한이 있는 권한 있는 보안 주체는 보존 기간을 단축하거나 제거할 수 있습니다.

• 규정 준수 모드: AWS 계정 루트를 포함한 어떤 사용자도 만료될 때까지 객체를 삭제 또는 덮어쓰거나 보존 기간을 줄일 수 없습니다. s3:PutObjectLegalHold 권한이 있는 사용자는 법적 보존을 추가로 적용하고 독립적으로 제거할 수 있습니다.

규정 준수 모드는 모든 자격 증명에 대해 절대적인 불변성이 요구될 때 올바른 선택입니다. 이 보증을 여러 리전으로 확장하려면 Object Lock을 S3 Replication과 함께 사용합니다. 복제된 객체는 대상 버킷(Object Lock이 활성화되어 있어야 함)에서 잠금 구성을 유지하므로, 리전 전체의 이벤트나 악의적인 삭제 시도로부터 보존된 사본을 보호할 수 있습니다.

검색 및 조사를 위한 Macie와 Athena

Amazon Macie는 관리형 및 사용자 지정 데이터 식별자를 사용하여 S3 객체에서 PII, PHI, 자격 증명 및 기타 민감한 패턴을 스캔합니다. 결과를 Security Hub 및 EventBridge에 보고하여, 제한적인 태그 기반 버킷 정책으로 객체를 격리하는 등의 자동화된 해결 조치를 활성화합니다. 고객 데이터를 저장하는 모든 리전에서 Macie를 활성화하고, 중앙 집중식 결과 관리를 위해 AWS Organizations를 통해 관리를 위임하십시오.

Amazon Athena는 S3의 데이터에 대한 서버리스 SQL을 제공하며, CloudTrail 객체 수준 데이터 이벤트를 쿼리하는 표준 도구입니다. 특정 S3 객체에 누가 액세스했는지 조사하려면, 해당 버킷에 대한 CloudTrail 데이터 이벤트를 활성화하고, 로그를 중앙 S3 버킷으로 전송한 다음, Athena로 쿼리합니다.

SELECT eventTime, userIdentity.arn, sourceIPAddress, requestParameters
FROM cloudtrail_logs
WHERE eventName IN ('GetObject','DeleteObject')
  AND requestParameters LIKE '%reports/q3-financials.pdf%'
  AND eventTime > '2024-01-01T00:00:00Z';

주요 함정과 근본 원인

• 객체 ARN에 /* 누락: 객체 수준 API 호출은 버킷 ARN이 아닌 bucket/key에 대해 평가됩니다. /*가 없으면 어떤 명령문도 일치하지 않아 IAM은 암시적 거부(implicit deny)를 반환합니다. 이로 인해 ‘버킷’이 허용된 것처럼 보여도 GetObject에서 예기치 않은 403 오류가 발생합니다.

• 명시적 Deny 이후에 Allow 추가: IAM 평가는 순서에 의존하지 않으며, 일치하는 Deny가 있으면 즉시 거부로 처리됩니다. 해결책은 허용 문을 추가하는 것이 아니라 Condition, NotPrincipal, 또는 NotResource를 통해 Deny의 범위를 좁히는 것입니다.

• OAC나 제한적인 버킷 정책 없이 CloudFront 사용: S3 오리진 URL에 직접 접근할 수 있어 서명된 URL, WAF 규칙, 지역 제한을 우회할 수 있습니다. 항상 오리진 버킷에 BPA를 활성화하고 AWS:SourceArn을 통해 s3:GetObject를 CloudFront 서비스 주체로 제한해야 합니다.

• 기존 버킷에 Object Lock을 활성화할 수 있다고 가정: Object Lock은 버킷 생성 시에 구성해야 합니다. 기존 버킷에 적용하려면 Object Lock이 활성화된 새 버킷을 만들고 데이터를 마이그레이션해야 합니다.

• 거버넌스 모드와 규정 준수 모드 혼동: 거버넌스 모드는 권한 있는 사용자가 보존 설정을 제거하는 것을 막지 못합니다. 루트 계정까지 차단하는 것은 규정 준수 모드뿐입니다.

실제 문제: 사용 사례 시나리오

시나리오: Meridian Financial은 두 AWS 리전에 걸쳐 여러 S3 버킷에 고객 명세서, 트랜잭션 로그, 장기 규정 준수 아카이브를 저장합니다. 이 환경은 고객 포털을 위해 CloudFront를 사용하고, 교차 계정 로깅 및 규제 보존을 위한 아카이브 스토리지 클래스로의 자동화된 수명 주기 전환을 활용합니다.

과제: 최근 내부 검토 결과, 여러 버킷에서 일관되지 않은 정책으로 인해 개인 식별 정보(PII)가 노출되고, 아카이브된 레코드에 대한 불변 보존이 없으며, 여러 계정과 리전에 걸쳐 민감한 객체가 어디에 있는지 발견할 중앙화된 방법이 없다는 점이 발견되었습니다.

권장 접근 방식:

1. 계정 및 버킷 수준에서 S3 퍼블릭 액세스 차단을 활성화하고 CloudFront Origin Access Control(OAC)을 배포합니다. 정확한 리소스 ARN을 사용하여 CloudFront OAC 주체로부터의 GetObject만 허용하도록 버킷 정책을 강화하고, OAC를 통하지 않는 모든 요청에 대해 명시적 거부를 추가합니다.
2. 버킷 정책에서 kms:Encrypt/kms:GenerateDataKey를 요구하여 AWS KMS를 사용한 서버 측 암호화를 강제하고, x‑amz‑server‑side‑encryption 및 필수 kms:context를 포함하지 않는 PutObject 요청에 대해 명시적 거부를 추가하여 암호화되지 않은 업로드를 방지합니다.
3. 불변성이 요구되는 버킷에 대해 S3 Object Lock을 규정 준수 모드로 구성하고, 복제된 객체가 DR 리전에서도 불변성을 유지하도록 객체 잠금 메타데이터를 보존하는 복제 규칙으로 교차 리전 복제(CRR)를 활성화합니다.
4. 오래된 객체를 S3 Glacier 스토리지 클래스로 전환하고 허용된 보존 기간 내에 객체가 만료되도록 S3 수명 주기 규칙을 생성합니다. 법적으로 불변해야 하는 아카이브의 경우, Amazon S3 Glacier 볼트에 배치하고 Glacier Vault Lock 정책을 적용하여 쓰기 방지(write-once) 보존을 강제합니다.
5. 여러 계정에 걸쳐 Amazon Macie를 배포하여 PII를 발견 및 분류하고, S3 인벤토리를 활성화한 후 Amazon Athena로 결과를 쿼리하여 조사하며, 자동화된 해결 조치(Lambda/Step Functions)를 트리거하여 민감한 객체를 태깅하거나, 격리하거나, 잠기고 암호화된 버킷으로 이동합니다.

근거: 이 계층적 접근 방식은 최소 권한 및 암호화를 강제하고, 규정 준수를 위한 불변 보존 및 교차 리전 내구성을 제공하며, Macie/Athena를 사용하여 중앙화된 검색 및 자동화된 해결 조치를 수행합니다. 이는 데이터 보호 및 수명 주기 관리에 대한 AWS 모범 사례와 일치합니다.

Amazon Macie: 자동화된 검색, 분류 작업 및 허용 목록

Amazon Macie는 기계 학습 및 패턴 매칭을 사용하여 Amazon S3에 저장된 민감 데이터(개인 식별 정보(PII), 결제 카드 번호(PAN), 자격 증명, 사용자 지정 정규식으로 정의된 데이터 유형)를 발견하는 관리형 데이터 보안 서비스입니다. Macie는 자주 혼동되는 두 가지 보완적인 모드로 작동합니다.

자동화된 민감 데이터 검색은 저비용으로 지속적으로 실행되는 프로세스로, 계정의 모든 버킷(또는 Macie가 보안 계정에 위임된 경우 조직 전체)에서 객체를 샘플링합니다. 이를 통해 버킷별 민감도 점수와 인벤토리를 구축합니다. 수천 개의 버킷이 있고 아직 민감 데이터가 어디에 있는지 모를 때 이것이 올바른 시작점입니다. 모든 객체를 스캔하는 대신 샘플링을 통해 비용과 관리 오버헤드를 최소화하기 때문입니다.

분류 작업(민감 데이터 검색 작업)은 특정 버킷을 대상으로 하는 일회성 또는 예약된 심층 스캔입니다. 자동화된 검색에서 버킷에 민감 데이터가 포함되어 있다고 플래그가 지정되면, 해당 버킷을 범위로 하는 분류 작업을 생성하여 철저한 분석을 수행합니다. 따라서 표준적인 패턴은 다음과 같습니다: 조직 전체에 자동화된 검색을 활성화한 다음, 플래그가 지정된 버킷에 대해서만 분류 작업으로 후속 조치를 취합니다.

허용 목록은 알려진 정상적인 일치 항목을 제외하는 메커니즘입니다. 데이터 레이크에 합성 테스트 PAN(예: 잘 알려진 4111 1111 1111 1111 테스트 카드 범위)이 포함되어 있으면 Macie는 모든 발생을 플래그 지정합니다. 데이터를 다시 쓰거나 이동하는 것은 비용이 많이 들고 번거롭습니다. 올바른 접근 방식은 Macie 허용 목록(정확한 값의 일반 텍스트 목록 또는 정규식)을 정의하고 이를 분류 작업 및 자동화된 검색 구성과 연결하는 것입니다. 허용 목록과 일치하는 항목은 결과에서 제외되지만, 실제 PAN은 계속해서 경고를 트리거합니다.

실제 문제: 사용 사례 시나리오

시나리오: Meridian Financial은 수백 개의 S3 버킷에 트랜잭션 로그, 고객 문서, S3 Glacier로 이동된 장기 아카이브를 저장하는 다중 계정 AWS 환경을 운영하고 있습니다. 보안팀은 기본적인 암호화와 로깅은 갖추고 있지만, 여러 계정에 걸쳐 중앙 집중식 민감 데이터 탐지나 일관된 보존 제어는 없는 상태입니다.

과제: 최근에 발견된 공개 버킷에 잘못된 버킷 정책과 S3 Glacier로의 수명 주기 전환으로 인해 개인 식별 정보(PII)가 포함된 고객 기록 아카이브가 들어 있었습니다. Meridian은 모든 민감한 데이터를 찾아 노출을 해결하고, 앞으로 규정을 준수하는 아카이브 보존 정책을 시행해야 합니다.

권장 접근 방식:

1. AWS Organization 전체에 Amazon Macie를 활성화하고 자동화된 S3 검색을 켜서 Macie가 지속적으로 버킷과 객체의 민감한 데이터 및 위험한 구성을 평가하도록 합니다.
2. 모든 S3 버킷을 대상으로 하는 Macie 분류 작업을 생성합니다. 주민등록번호(SSN) 및 계좌 번호에 대한 사용자 지정 민감 데이터 식별자를 구성하고, 알려진 테스트 데이터, 공급업체 파일, 서비스 계정을 제외하기 위한 허용 목록을 설정합니다.
3. S3 Inventory를 사용하여 S3 Glacier의 객체 목록을 생성한 다음, S3 Batch Operations를 실행하여 Macie 스캔을 위해 인벤토리에서 플래그가 지정된 객체만 일시적으로 복원하여 분류 작업이 Glacier에 보관된 콘텐츠를 검사할 수 있도록 합니다.
4. Macie 탐지 결과를 Amazon EventBridge 및 Security Hub로 전송하여 해결 조치를 자동화합니다. Lambda 함수를 트리거하여 보안 S3 버킷 정책을 적용하고, S3 퍼블릭 액세스 차단을 활성화하며, 퍼블릭 ACL을 제거하고, 검토가 필요한 버킷에 태그를 지정합니다.
5. 중요 버킷에 S3 Versioning 및 S3 Object Lock(거버넌스/규정 준수 모드)을 활성화하여 영구적인 보존 및 방지책을 구현합니다. 버킷 정책을 통해 CMK를 사용한 SSE-KMS를 강제하고, AWS Organizations SCP를 배포하여 퍼블릭 ACL을 차단하고 해당되는 경우 암호화 및 Object Lock을 요구합니다.
6. S3에 대한 CloudTrail 데이터 이벤트를 활성화하고 탐지 결과를 SIEM으로 보내 경보를 발생시키고, 주기적인 Macie 분류 작업을 예약하여 지속적인 커버리지를 보장합니다.

근거: 이 접근 방식은 Macie를 사용하여 자동화된 탐지 및 대상 분류(허용 목록 포함)를 수행하고, 검사를 위해 필요한 경우에만 Glacier 객체를 복원하며, EventBridge/Lambda를 통해 해결 조치를 자동화하고, Object Lock 및 KMS로 불변의 보존 및 암호화를 강제합니다. 이는 탐지, 해결 및 예방 제어에 대한 AWS 모범 사례와 일치합니다.

# Example allow list (regex form) matching common test PANs
Type: Regex
Regex: '^4111[- ]?1111[- ]?1111[- ]?1111$|^5555[- ]?5555[- ]?5555[- ]?4444$'
Name: synthetic-test-pans

허용 목록이나 억제 목록을 구성하지 않고 원시 Macie 탐지 결과를 그대로 신뢰하면 경보 피로를 유발하고, 합성 데이터로 인한 노이즈 속에 실제 사고를 가릴 수 있습니다. 이것이 바로 오탐이 많은 환경에서 단순히 ‘탐지 결과를 신뢰하는 것’이 잘못된 답변인 이유입니다.

Macie 탐지 결과를 EventBridge와 통합하기

Macie는 모든 탐지 결과를 aws.macie 소스로 Amazon EventBridge에 게시합니다. 이를 통해 Macie API를 폴링하지 않고도 탐지 결과를 라우팅할 수 있습니다. 일반적인 규칙은 Policy 탐지 결과를 SNS로 전달하여 온콜 담당자에게 알리고, SensitiveData 탐지 결과를 AWS Security Hub로 보내 집계합니다.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

규칙의 대상은 SNS 주제, Security Hub 또는 사용자 지정 해결 조치를 위한 Lambda 함수입니다(예: 문제가 되는 버킷에 제한적인 버킷 정책을 자동으로 적용).

조직 경계를 위한 버킷 정책 조건

S3 퍼블릭 액세스 차단(BPA)은 퍼블릭 인터넷이나 익명 보안 주체로부터 시작되는 액세스만 차단합니다. 버킷 정책이나 ACL이 액세스를 허용하는 경우, 다른 AWS 계정이나 다른 AWS Organization의 인증된 보안 주체가 버킷에 액세스하는 것을 막지는 않습니다. 따라서 조직 간 액세스를 방지해야 하는 요구사항이 있을 때 BPA에만 의존하는 것은 올바르지 않습니다. 버킷 정책을 Organizations 수준의 서비스 제어 정책(SCP)과 결합해야 합니다.

두 가지 IAM 조건 키를 사용하면 조직 경계 적용을 정밀하게 할 수 있습니다.

• aws:ResourceOrgID: 액세스되는 리소스를 소유한 Organization ID입니다. ID 정책/SCP에서 보안 주체가 조직 외부의 리소스를 건드리지 못하도록 거부하는 데 사용됩니다.

• aws:PrincipalOrgID: 호출하는 보안 주체의 Org ID입니다. 버킷 정책에서 조직 외부의 보안 주체로부터의 액세스를 거부하는 데 사용됩니다.

• aws:SourceOrgPaths: 소스 보안 주체의 OU 경로로, 특정 OU로 범위를 지정할 수 있습니다(예: ‘Production’ OU만 규정 준수 버킷에 쓸 수 있도록 허용).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideOrg",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:DeleteObject"],
    "Resource": "arn:aws:s3:::acme-compliance/*",
    "Condition": {
      "StringNotEqualsIfExists": {
        "aws:PrincipalOrgID": "o-abcd1234",
        "aws:SourceOrgPaths": "o-abcd1234/r-root/ou-prod-xyz/"
      }
    }
  }]
}

이를 aws:ResourceOrgID가 조직과 일치하지 않는 리소스에 대해 s3:DeleteObject*를 거부하는 SCP와 함께 사용하면, 버킷 정책이 실수로 완화되더라도 조직 간 데이터 유출이나 삭제가 불가능해집니다.

S3 Object Lock: 규정 준수 모드와 버전 관리

Object Lock은 개별 객체 버전에 대해 WORM(Write-Once-Read-Many) 시맨틱을 적용합니다. 이를 위해서는 버킷에 S3 Versioning이 활성화되어 있어야 합니다(버전 관리 없는 Object Lock은 불가능합니다. 잠금은 키가 아닌 특정 버전 ID를 보호합니다).

• 거버넌스 모드: s3:BypassGovernanceRetention 권한이 있는 사용자는 보존 기간을 단축하거나 제거할 수 있습니다. 내부 정책 시행에 적합합니다.

• 규정 준수 모드: AWS 계정 루트를 포함한 어떤 보안 주체도 보존 기간이 만료될 때까지 객체 버전을 단축, 제거 또는 삭제할 수 없습니다. 이는 규제 불변성 요구사항(SEC 17a-4, FINRA, HIPAA 아카이브)에 대한 올바른 선택입니다.

보존 기간은 객체별(Retain-Until 날짜) 또는 기본 버킷 수준 보존 구성을 통해 설정할 수 있습니다. 법적 보존(Legal Hold)은 별도의 무기한 잠금으로, s3:PutObjectLegalHold 권한을 가진 보안 주체가 명시적으로 제거할 때까지 유지됩니다.

aws s3api put-object-retention \
  --bucket acme-audit-logs \
  --key 2024/transactions.parquet \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2031-01-01T00:00:00Z"}'

S3 Glacier Vault Lock: 잠금 완료 전 정책 오류 수정하기

S3 Glacier의 Vault Lock은 변경 불가능한 볼트 액세스 정책을 강제합니다. 이 프로세스는 두 개의 API 호출로 이루어집니다. initiate-vault-lock은 정책을 24시간의 유예 기간을 갖는 진행 중(in-progress) 상태로 만들고, complete-vault-lock은 이를 영구적으로 만듭니다. 만약 24시간의 유예 기간 동안 오타가 발견된다면(예: 과도하게 허용적인 Principal 설정), 가장 정확하고 저렴한 해결 방법은 다음과 같습니다.

aws glacier abort-vault-lock --account-id - --vault-name compliance-archive
aws glacier initiate-vault-lock --account-id - --vault-name compliance-archive \
  --policy file://corrected-policy.json

abort-vault-lock은 비용 없이 진행 중인 잠금을 취소하고, 수정된 정책으로 다시 시작할 수 있게 해줍니다. 다른 “수정” 방법들, 예를 들어 볼트를 삭제하고 다시 생성하거나(이 경우 10TB의 모든 아카이브를 삭제하고 다시 업로드해야 하므로 검색 및 전송 요금이 발생합니다), 또는 잠금이 완료될 때까지 기다렸다가 우회하는 방법은 낭비적이거나 불가능합니다. complete-vault-lock이 실행되면 정책은 영원히 변경할 수 없게 되며, 잠금 중단은 진행 중(in-progress) 상태인 기간에만 유효합니다.

관련된 함정: DNSSEC 신뢰 사슬

도메인 간에 흔히 발생하는 함정은 Route 53 DNSSEC와 관련이 있습니다. 하위 도메인의 호스팅 영역에서 DNSSEC 서명을 활성화하면 KSK(키 서명 키)와 그에 해당하는 DS 레코드가 생성됩니다. 이 DS 레코드는 반드시 상위(parent) 영역에 게시되어야 합니다. 이것이 없으면 리졸버는 신뢰 사슬을 검증할 수 없으며, 응답을 가짜로 처리하거나 안전하지 않은 확인 방식으로 대체하게 되어, 검증을 수행하는 클라이언트의 DNS가 중단됩니다. DS 레코드를 내보내서 등록 기관이나 상위 영역에 삽입하지 않고 서명만 활성화하는 것은 구성이 완료되지 않은 상태이며, 제대로 작동하는 DNSSEC 배포가 아닙니다.

← 암호화 · 모든 도메인 · 네트워킹 및 VPC 보안 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Amazon 찾아보기 →