GN⁺: S3에 대해 알지 않았으면 하는 것들

AWS S3 버킷 암호화는 생각만큼 간단하지 않음

S3 암호화 옵션들

• 서버 측 암호화 (SSE-S3): AWS가 관리하는 키를 사용해 데이터를 암호화함.
• 서버 측 암호화 (SSE-KMS): AWS 키 관리 서비스(KMS)를 사용해 데이터를 암호화함.
• 서버 측 암호화 (SSE-C): 사용자가 제공한 키를 사용해 데이터를 암호화함.
• 클라이언트 측 암호화: 사용자가 데이터를 업로드하기 전에 직접 암호화함.

암호화와 접근 제어의 차이

• 암호화: 데이터를 보호하기 위해 데이터를 변환하는 과정임.
• 접근 제어: 누가 데이터에 접근할 수 있는지를 결정하는 정책임.
• S3 암호화는 실제로는 접근 제어에 더 가깝고, 데이터 보호보다는 접근 권한 관리에 중점을 둠.

왜 중요한가

• 보안: 암호화는 데이터 유출 시에도 데이터를 보호할 수 있음.
• 규정 준수: 특정 산업 규제나 법적 요구사항을 충족하기 위해 암호화가 필요할 수 있음.
• 데이터 무결성: 암호화는 데이터가 변조되지 않았음을 보장함.

GN⁺의 의견

• 암호화와 접근 제어의 혼동: 많은 사람들이 암호화와 접근 제어를 혼동함. 이 기사는 그 차이를 명확히 설명해줌.
• 실제 보안 수준: S3의 암호화 옵션이 실제로 얼마나 안전한지에 대한 비판적인 시각이 필요함.
• 대안 기술: S3 외에도 Google Cloud Storage나 Azure Blob Storage 같은 다른 클라우드 스토리지 서비스도 고려해볼 만함.
• 사용자 교육: 초급 엔지니어들에게 암호화와 접근 제어의 차이를 명확히 이해시키는 것이 중요함.
• 기술 도입 시 고려사항: 암호화 기술을 도입할 때 성능 저하, 비용 증가 등의 요소를 고려해야 함.

[neo]

Hacker News 의견

• 파일 시스템이 대소문자를 구분하는 것에 대한 불만에 동의하지 않음. 이는 당연한 것이며, macOS가 이를 지원하지 않는 것이 불편함.
• S3 경로는 실제 디렉토리가 아닌 시뮬레이션임. 예를 들어, /builds/1/installer.exe는 실제로는 이름에 /가 포함된 파일임.
• S3나 다른 AWS 서비스를 사용하는 것이 복잡하고 문서가 많아 실수로 데이터를 노출할 수 있음. Hetzner Storage Boxes나 DigitalOcean Spaces 같은 단순한 서비스를 선호함.
• 수십억 개의 객체를 삭제하는 것은 비용이 많이 들 수 있음. 그러나 와일드카드나 버킷 전체 객체 만료 시간을 설정하면 무료로 즉시 스토리지 요금을 중지할 수 있음.
• 실패한 멀티파트 업로드가 보이지 않게 남아 있어 스토리지 비용이 발생할 수 있음. S3의 'Simple'이라는 이름이 무색함.
• 멀티파트 업로드는 여러 머신에서 수행할 수 없으며, LIST 요청은 느리고 비용이 많이 듦. 버킷 생성은 일관성이 없을 수 있음.
• S3는 대소문자를 구분하며, 이는 파일 시스템 구조로 변환할 때 문제가 될 수 있음.
• 대부분의 S3 구성은 GET 요청을 허용하지만 HEAD 요청은 허용하지 않음. 캐시를 활용한 흐름이 작동하지 않을 수 있음.
• 사전 서명된 URL을 많이 사용하는 경우, URL 생성 속도를 10배에서 40배까지 향상시킬 수 있음.
• 완료되지 않은 멀티파트 업로드에 대해 스토리지 비용을 지불해야 함. 자동 삭제 설정을 활성화해야 함.
• 대소문자 구분 논의가 너무 영어 중심적임.
• S3는 단일 TCP 연결이 100개의 HTTP 요청을 보낸 후 모든 요청을 조용히 무시함.
• 잘못 구성된 웹사이트가 사용자 콘텐츠를 Amazon Glacier에 업로드하고 나중에 제공할 수 있음.
• S3는 높은 지연 시간 때문에 웹 서빙에 적합하지 않음. 작은 객체의 일관된 지연 시간은 100-200 밀리초임.