< Best Practices for Using Cloud Storage (Part 1) >
Follow these best practices for naming
다음과 같은 이름 지정 모범 사례를 따르자
- Google Cloud Storage 버킷 이름은 전역적으로 공개되며 전체 Google Cloud Storage 서비스에서 고유해야 함
- 애플리케이션에 많은 버킷이 필요한 경우 버킷 이름에 GUID 또는 이에 상응하는 것을 사용
- 버킷 이름을 생성할 때 애플리케이션에는 이름 충돌을 처리하기 위한 재시도 로직이 필요
- 버킷을 상호 참조할 수 있도록 목록을 유지하는 것이 좋음
- 다른 리소스의 존재 여부를 조사하는 데 사용할 수 있는 버킷 이름의 정보를 사용하지 말아야 함
- 개체 또는 버킷 이름에 개인 식별 정보를 입력하는 경우 URL에 표시되기 때문에 주의
- 버킷 이름은 CNAME 리디렉션의 일부로 DNS 레코드에 나타날 수 있으므로 버킷 이름은 표준 DNS 명명 규칙 준수 필요
- 회사 도메인 이름의 일부를 버킷 이름에 사용하는 경우(정방향 또는 역방향)
Google은 귀하가 도메인을 소유하고 있는지 확인하려고 시도할 것임 - DNS Admin이 소유권을 확인할 수 없는 경우 버킷에서 회사 도메인 이름을 사용하지 말아야 함
Follow these best practices for Cloud Storage traffic
Cloud Storage 트래픽에 대해 다음 권장사항을 따르자
- Cloud Storage로 애플리케이션을 설계할 때 초당 작업, 대역폭(시간 프레임에 전송되는 데이터 양), 캐시 제어를 고려
- 객체에 대한 Cache-Control 메타데이터를 지정하면 핫하거나 자주 액세스하는 객체에 대한 읽기 대기 시간이 낮아짐 - 트래픽 급증을 최소화하고 하루 종일 업데이트를 배포하도록 애플리케이션을 설계
- 오류가 발생하면 지수 백오프를 사용
- Google Storage에는 요청 비율에 대한 상한선이 없지만 높은 요청 비율로 확장할 때 최상의 성능을 얻으려면
요청 비율 및 액세스 배포 지침을 따라야 함
- 요청 속도가 초당 쓰기 요청 1000개 또는 읽기 요청 초당 5000개 미만이면 램프업이 필요하지 않음
- 요청 비율이 이러한 임계값을 초과할 것으로 예상되는 경우
임계값 이하 또는 가까운 요청 비율로 시작한 다음 20분마다 요청 비율을 두 배로 늘려야 함
Consider the location and availability of your data
데이터의 위치와 가용성 고려
- 스토리지 옵션을 선택할 때 데이터의 위치와 필요한 가용성을 고려
- 애플리케이션 사용자와 가장 가까운 지역에 데이터를 저장하고 데이터 위치를 선택할 때 지역별 규정 준수 요구 사항을 고려
- 분석 워크로드의 경우 데이터를 지역 버킷에 저장하여 다중 지역 또는 이중 지역에 비해 네트워크 요금을 줄이고 성능을 향상시킴
Consider the characteristics of your data
데이터의 특성 고려
- Standard Storage는 최저 운영 비용과 최소 기간 없이 스토리지 클래스의 최상의 가용성을 제공하나 월별 보관 가격이 더 높음
- Standard Storage는 고가용성으로 높은 속도로 제공되는 데이터에 적합한 옵션 - Nearline Storage 및 Coldline Storage는 액세스 빈도가 낮은 데이터와 약간 낮은 가용성을 허용하는 데이터에 적합한 옵션
- 최소 저장 기간이 각각 30일 및 90일인 경우 운영 비용은 아카이브 저장소보다 저렴하고 저장소 비용은 표준 저장소보다 저렴 - Archive Storage는 법적 또는 규제상의 이유로 저장된 데이터 또는 데이터 복구에 필요한 데이터와 같이
1년 미만으로 액세스되는 데이터에 적합
- Archive Storage에는 가용성 SLA가 없지만 일반적인 가용성은 Nearline Storage 및 Coldline Storage와 비슷
- Archive Storage는 최소 저장 기간이 365일인 월별 저장 요금이 가장 저렴
Secure your buckets using the following options
다음 옵션을 사용하여 버킷 보호
- 이러한 옵션을 사용하여 Cloud Storage 버킷 및 객체에 대한 액세스를 제어할 수 있음
- Cloud Identity and Access Management 권한을 사용하여 버킷에 대한 액세스 권한을 부여하고
버킷의 객체에 대한 일괄 액세스를 제공
- Cloud IAM 권한으로는 개별 객체를 세밀하게 제어할 수 없음 - 액세스 제어 목록(ACL)을 사용하여 개별 버킷 또는 객체에 대한 읽기 또는 쓰기 액세스 권한을 사용자에게 부여할 수 있으므로
개별 개체를 세밀하게 제어해야 하는 경우에만 ACL을 사용하는 것이 좋음 - 서명된 URL의 쿼리 문자열 인증을 사용하여 생성한 URL을 통해 개체에 대한 시간 제한 읽기 또는 쓰기 액세스를 제공
- 공유 URL은 지정된 기간 동안 공유된 모든 사람에게 액세스를 제공
- gsutil을 사용하거나 애플리케이션에서 프로그래밍 방식으로 서명된 URL을 만들 수 있음 - 서명된 정책 문서를 통해 버킷에 업로드할 수 있는 항목을 지정할 수 있음
- 서명된 URL을 사용하는 것보다 크기, 콘텐츠 유형 및 기타 업로드 특성을 더 잘 제어할 수 있음
- 방문자가 Cloud Storage에 파일을 업로드할 수 있도록 웹사이트 소유자가 사용
- 서명된 정책 문서는 양식 게시물에서만 작동 - Firebase 보안 규칙은 Cloud Storage용 Firebase SDK를 사용하여
모바일 및 웹 애플리케이션에 대한 세분화된 속성 기반 액세스 제어를 제공
Consider these additional security best practices
이러한 추가 보안 모범 사례를 고려
- 가능하면 항상 TLS를 사용하여 데이터를 전송
- 이렇게 하면 네트워크를 통해 자격 증명과 데이터를 전송할 때 자격 증명과 데이터가 모두 보호 - 서버 인증서의 유효성을 검사하는 HTTPS 라이브러리를 사용하고 있는지 확인
- 서버 인증서 유효성 검사가 부족하면 애플리케이션이 메시지 가로채기 공격 또는 기타 공격에 취약해짐
- 일반적으로 사용되는 특정 구현 언어와 함께 제공되는 HTTPS 라이브러리는 기본적으로 서버 인증서를 확인하지 않음 - 애플리케이션이 더 이상 데이터에 액세스할 필요가 없으면 권한을 제거하거나 인증 자격 증명을 취소해야 함
- 자격 증명을 안전하게 저장했는지 확인
- 많은 수의 사용자를 명시적으로 나열하는 대신 그룹을 사용하는 것을 선호
- 그룹이 더 잘 확장될 뿐만 아니라 한 번에 많은 수의 개체에 대한 액세스 제어를 업데이트하는 매우 효율적인 방법을 제공 - 버킷에 객체를 추가하기 전에 기본 객체 ACL이 요구 사항에 맞게 설정되어 있는지 확인
- 이렇게 하면 개별 개체에 대한 ACL을 업데이트하는 데 많은 시간을 절약할 수 있음
- 버킷과 객체 ACL은 서로 독립적임 즉, 버킷의 ACL은 해당 버킷 내부의 객체에 대한 ACL에 영향을 미치지 않음
- 버킷에 대한 권한이 없는 사용자가 버킷 내부의 객체에 대한 권한을 가질 수 있음 - Cloud Storage는 버킷의 객체를 공개적으로 읽을 수 있도록 지정하는 기능을 제공
- 버킷을 공개적으로 읽을 수 있게 만든 후에는 누구나 버킷에서 데이터를 복사할 수 있음
- 이 권한으로 작성된 개체에 대한 읽기 제어를 다시 얻는 것은 사실상 불가능하므로 필요한 경우에만 이 액세스를 제공
- Cloud Storage 버킷을 공개적으로 구성하면 다양한 용도로 편리할 수 있지만 사용하지 않는 것이 좋음
- 불법 콘텐츠, 바이러스 및 기타 악성코드 배포에 악용될 수 있으며
버킷 소유자는 버킷에 저장된 콘텐츠에 대해 법적 및 재정적 책임을 질 수 있음
Consider retention policies and retention policy locks
보존 정책 및 보존 정책 잠금 고려
- 버킷 잠금 기능을 사용하면
버킷의 객체를 보관해야 하는 기간을 제어하는 Cloud Storage 버킷에 대한 데이터 보관 정책을 구성할 수 있음
- 또한 이 기능을 사용하면 데이터 보존 정책을 잠글 수 있어 정책이 축소되거나 제거되는 것을 영구적으로 방지할 수 있음 - 보존 정책 및 보존 정책 잠금을 사용할 때 고려해야 할 몇 가지 사항이 있음
- 버킷에 보존 정책을 추가하여 보존 기간을 지정할 수 있음
- 버킷에 보존 정책이 없으면 언제든지 버킷의 객체를 삭제하거나 교체할 수 있음
- 버킷에 보존 정책이 있는 경우 버킷의 객체는 보존 기간보다 오래된 경우에만 삭제하거나 교체할 수 있음
- 보존 정책은 버킷의 기존 객체와 버킷에 추가된 새 객체에 소급 적용
- 보존 정책을 잠가 버킷에 영구적으로 설정할 수 있음
- 보존 정책을 잠그면 제거하거나 보존 기간을 줄일 수 없음
- 버킷의 모든 객체가 보존 기간을 충족하지 않으면 잠긴 보존 정책이 있는 버킷을 삭제할 수 없음
- 잠긴 보존 정책의 보존 기간을 늘릴 수 있음
- 보존 정책을 잠그면 데이터가 기록 보존 규정을 준수하는 데 도움이 될 수 있음
(online) 05_Performing Operations on Cloud Storage.pdf
2.06MB
