S3 버킷에 대한 기본 보호

I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line and all formatting exactly as you requested.

암호화

암호화는 읽을 수 있는 정보(예: 비밀 마스터 플랜)를 읽을 수 없는 형식으로 변환하여 권한이 있는 당사자만 접근할 수 있도록 합니다. 자세한 내용은 여기서 중요하지 않으며, 암호화가 필수적이라는 것만 알아두세요.

대부분 마주하게 되는 암호화는 두 가지 범주로 나뉩니다:

*“사용 중 암호화”*는 별도의 주제이며 이 글의 범위에 포함되지 않습니다.

정지 상태에서의 암호화

정지 상태에서의 암호화는 저장소에 그대로 있는 데이터를 보호합니다. 최상비밀 노트북을 보관하는 금고와 같으며, 조합을 아는 사람만 열 수 있습니다.

Amazon S3에서는 객체를 암호화하는 두 가지 주요 방법이 있습니다:

좋은 소식: 버킷은 기본적으로 정지 상태 암호화가 활성화되어 있습니다. 업로드하는 모든 객체는 Amazon S3 관리 키(SSE‑S3)를 사용한 서버 측 암호화로 자동 보호됩니다. 이는 투명하게 적용되며 추가 비용이 발생하지 않습니다.

• 대부분의 사용 사례에서는 SSE‑S3가 충분합니다.
• 더 많은 제어가 필요하면 KMS 관리 키(SSE‑KMS)를 사용하거나 클라이언트 측에서 암호화할 수 있습니다.

전송 중 암호화

전송 중 암호화는 데이터가 이동하는 동안 보호합니다—예를 들어 파일을 S3에서 장치로 다운로드할 때. 이를 사용하지 않으면 트래픽을 가로채는 사람이 데이터를 읽을 수 있습니다.

이는 비대칭 암호화(공개키/비공개키 쌍)를 사용하여 보안 채널을 구축함으로써 달성됩니다:

• 공개키 – 우편함 슬롯과 같으며, 누구나 편지를 넣을 수 있습니다(데이터 암호화).
• 비공개키 – 우편함을 여는 열쇠와 같으며, 소유자만 편지를 읽을 수 있습니다(데이터 복호화).

S3 버킷에 접근하는 방법:

• HTTP – 암호화되지 않음(권장되지 않음)
• HTTPS – 암호화됨(권장)

추천: 접근은 오직 HTTPS만 허용하십시오. TLS가 아닌 요청을 거부하는 버킷 정책으로 이를 강제합니다:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictToTLSRequestsOnly",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

your-bucket-name을 실제 버킷 식별자로 교체하십시오. 이 정책은 일반 HTTP로 이루어진 모든 요청을 거부하여 모든 데이터 전송이 TLS 암호화를 사용하도록 보장합니다.

Source: …

퍼블릭 vs. 프라이빗 버킷

AWS에는 두 가지 버킷 액세스 유형이 있습니다:

참고: 새 버킷은 기본적으로 프라이빗입니다. 버킷을 퍼블릭으로 만들려면 명시적인 절차가 필요하며, 실수하기 쉽습니다. 계층화된 방어를 추가하면 실수로 인한 노출을 방지할 수 있습니다.

Block Public Access

Block Public Access 기능은 의도치 않은 퍼블릭 노출을 차단합니다. 이 기능은 세 가지 범위에 적용될 수 있습니다:

최소 권한

최소 권한 원칙은 엔터티(사람, 애플리케이션 또는 서비스 계정)에게 특정 작업을 수행하는 데 필요한 최소 권한만 부여하고 그 이상은 부여하지 않아야 한다는 것을 의미합니다.

이 원칙을 적용하면 실수로 인한 오용이나 악의적인 활동의 위험을 줄일 수 있습니다. S3 데이터를 보호하려면:

• IAM 권한을 신중하게 범위 지정하여 사용자와 서비스가 실제로 필요한 버킷 및 작업에만 접근하도록 합니다.
• 예시: 버킷에 마케팅 정보가 저장되어 있다면, 마케팅 팀만 접근 권한을 가져야 합니다.

Note: 최소 권한은 한 번만 수행하는 작업이 아닙니다. 책임이 변하거나 팀이 재구성되거나 접근 요구 사항이 변화함에 따라 지속적인 유지 관리와 정기적인 감사가 필요합니다.

버전 관리 및 MFA 삭제

여기서 기사 계속…

버전 관리

버킷에서 버전 관리가 활성화되면, S3는 객체를 영구적으로 교체하거나 삭제하는 대신 여러 버전을 보관합니다. 이를 통해 파일이 실수로 삭제되거나 수정된 경우 이전 버전을 복구할 수 있습니다.

Note: 이 기능은 버킷에 한 번 활성화하면 비활성화할 수 없으며, 추가로 저장되는 버전 때문에 추가 비용이 발생합니다.

MFA Delete

MFA Delete를 활성화하면 S3 버킷에 추가적인 보호 장치가 추가됩니다. MFA Delete가 켜져 있을 때, 사용자는 정상적인 자격 증명 외에 유효한 다중 인증(MFA) 토큰을 제공해야만 다음과 같은 민감한 작업을 수행할 수 있습니다:

• 객체 버전 영구 삭제
• 버킷에 대한 버전 관리 중단

이 추가 단계는 공격자가 사용자의 자격 증명을 입수하더라도 MFA 장치에 물리적으로 접근하지 않으면 파괴적인 작업을 수행할 수 없도록 보장합니다.

요약

versioning와 MFA Delete를 함께 사용하면 인간 실수나 악의적인 활동으로 인한 데이터 손실에 대한 효과적인 보호 수단을 제공합니다.

팁: S3 버킷에 versioning 및 MFA Delete를 활성화하여 실수나 악의적인 삭제로부터 보호하십시오.