클라우드 스토리지 공개 설정 점검 방법 5단계
- 공개 링크와 익명 권한은 저장소 정책과 파일별 공유 설정을 함께 확인합니다.
- 상속된 권한과 만료되지 않은 공유 링크도 점검합니다.
- 차단 전 서비스 영향을 살피고 변경 후 외부 접근을 재검증합니다.
클라우드 스토리지 공개 설정은 저장소 전체의 차단 옵션만 보는 것으로 끝나지 않습니다. 계정·버킷·폴더·파일에 적용된 권한과 공유 링크를 함께 확인해야 합니다. 먼저 공개 접근을 허용하는 항목을 찾고, 필요한 공개 사용처인지 확인한 다음 권한을 줄이고 외부 접근을 재검증하세요.
공개 설정 점검에서 먼저 구분할 것

누구나 접근하는 공개 권한
공개 권한은 로그인이나 별도 초대 없이 인터넷 사용자가 파일을 읽을 수 있는 설정입니다. Google Cloud Storage에서는 IAM 주체 allUsers가 공개 접근을 뜻할 수 있고, AWS S3에서는 버킷 정책이나 ACL이 공개 읽기를 허용할 수 있습니다. Azure Blob Storage에서는 계정 설정이 컨테이너의 익명 접근 허용 여부에 영향을 줍니다. 제품마다 표현은 다르므로 공개, 익명, 모든 사용자, 누구나와 같은 항목을 확인하세요.
링크가 있는 사람 또는 특정 사용자 공유
링크 공유는 저장소를 공개하는 설정과 다를 수 있지만, 링크를 전달받은 사람도 접근할 수 있는 유형이라면 통제 범위가 넓어집니다. Microsoft OneDrive의 ‘링크가 있는 모든 사용자’ 옵션은 Microsoft 계정 로그인 없이 접근할 수 있으며, 링크를 받은 사람이 다른 사람에게 전달할 수도 있습니다. ‘특정 사용자’ 링크, 조직 내부 링크, 만료일이 있는 링크를 공개 접근과 구분해 검토하세요.
기억할 기준: 파일 URL을 안다는 이유만으로 접근할 수 있는지, 접근 전에 계정 로그인이나 초대가 필요한지 확인하세요. 링크가 있다는 사실만으로 공개라고 단정하지 말고 링크 종류와 권한을 살펴야 합니다.
클라우드 공개 설정 점검 5단계

1단계: 점검 범위와 소유자를 정합니다
사용 중인 서비스와 계정을 목록으로 만들고, 개인 계정·프로젝트·조직 계정 및 운영·개발·백업 환경을 구분합니다. 저장소 이름, 담당자, 용도, 공개가 필요한 이유를 기록하면 오래된 테스트 버킷이나 퇴사자 소유 파일도 찾기 쉽습니다. 콘솔 권한이 부족해 목록이나 정책을 볼 수 없다면 임의로 판단하지 말고 해당 관리자에게 확인을 요청하세요.
2단계: 공개 설정과 링크를 검색합니다
서비스의 보안 권고 도구와 공유 목록을 활용해 공개 버킷, 익명 읽기, ‘누구나’ 링크를 찾습니다. 저장소 단위 정책뿐 아니라 폴더 및 파일의 개별 권한, 조직이나 프로젝트에서 상속된 설정, 접근제어목록(ACL, 파일별 권한을 지정하는 방식)도 살펴보세요. 링크 공유는 파일 소유자 화면의 공유 관리에서 확인할 수 있습니다.
3단계: 업무상 공개가 필요한지 판정합니다
발견 항목마다 데이터 민감도, 실제 이용자, 노출 범위, 공개 목적, 책임자를 확인합니다. 공개 웹사이트 이미지처럼 의도된 공개 파일은 운영 경로와 개인·업무 자료가 섞이지 않도록 별도 저장소로 분리하는 편이 관리하기 쉽습니다. 목적과 소유자를 확인할 수 없는 공개 권한은 그대로 두지 말고 담당 부서에 확인할 항목으로 표시합니다.
4단계: 필요한 권한만 남기고 조정합니다
불필요한 공개 권한은 제거하고, 협업 공유는 가능한 경우 특정 사용자나 조직 계정으로 제한합니다. 보기 권한이면 충분한데 편집 권한이 부여되어 있지는 않은지도 확인하세요. 계정 전체의 공개 차단을 켜기 전에는 공개 웹사이트, 배포 파일, 연동 서비스가 영향을 받는지 검토하고 변경 담당자와 복구 방법을 정합니다.
5단계: 외부 접근과 기록을 확인합니다
변경 뒤 공개 URL을 로그아웃 상태의 별도 브라우저에서 확인하거나, 서비스의 권한 검사 도구로 결과를 검증합니다. 접근이 막혔다는 응답만 확인하지 말고, 의도한 사용자와 애플리케이션은 계속 접근할 수 있는지도 함께 점검하세요. 조치 전후 설정, 담당자, 확인 시각, 예외 승인 사유를 기록하고 정기 점검 대상에 포함합니다.
서비스별로 어디를 확인할까

| 서비스 | 확인할 설정 | 주의할 점 |
|---|---|---|
| AWS S3 | 계정·버킷 Block Public Access, 버킷 정책, ACL, IAM Access Analyzer | 조직·계정·버킷에 적용된 차단 설정을 함께 확인합니다. |
| Google Cloud Storage | Public access prevention, 버킷 IAM, ACL, Cloud Asset Inventory | allUsers와 allAuthenticatedUsers 권한을 확인합니다. |
| Azure Blob Storage | 계정의 익명 Blob 접근 허용, 컨테이너 접근 수준 | 정적 웹 사이트 기능은 별도 공개 동작을 할 수 있으므로 따로 확인합니다. |
| OneDrive | 공유됨 목록, 파일의 액세스 관리, 링크 종류와 권한 | ‘링크가 있는 모든 사용자’는 전달된 링크로도 접근할 수 있습니다. |
AWS는 S3의 Block Public Access 설정 안내와 IAM Access Analyzer 점검 안내에서 공개 접근 차단 및 외부 접근 검토 방법을 제공합니다. Google Cloud는 Cloud Storage 공개 액세스 방지 문서에서 버킷 설정과 조직 정책의 동작을 설명합니다. Microsoft는 Azure 익명 Blob 읽기 접근 설정 문서에서 계정과 컨테이너 설정의 관계를 안내하며, Azure Blob Storage 보안 문서는 정적 웹 사이트 기능이 공개 콘텐츠에 영향을 줄 수 있음을 설명합니다. OneDrive의 ‘링크가 있는 모든 사용자’ 동작은 Microsoft 외부 또는 게스트 공유 안내에서 확인할 수 있습니다.
차단 후에도 확인해야 할 예외와 실수

- 저장소만 보고 파일 권한을 놓침: 제품에 따라 객체 ACL이나 폴더 권한이 별도로 남을 수 있습니다.
- 공유 링크를 공개 설정과 혼동함: 로그인 없이 누구나 쓸 수 있는 링크인지, 특정 사용자만 쓸 수 있는지 구분합니다.
- 기존 공개 기능의 영향 누락: 공개 웹사이트나 배포 파일을 차단하면 사용자 서비스가 중단될 수 있으므로 변경 전 의존성을 확인합니다.
- 차단만 하고 기존 권한을 방치함: 차단 설정이 권한을 덮어쓰더라도 정책이나 링크가 설정에 남아 있다면 차단 해제나 설정 변경 때 다시 노출될 수 있습니다.
- 접근 링크만 삭제하고 사본을 놓침: 공유된 파일의 다운로드본이나 다른 저장 위치의 사본은 별도로 확인해야 합니다.
공개 차단 상태는 권한 설정을 대신하는 만능 해법이 아닙니다. 공개 차단, 실제 정책 검토, 외부 접근 재확인을 함께 해야 변경 뒤에도 노출 가능성을 낮출 수 있습니다.
예를 들어 Google Cloud의 공개 액세스 방지는 allUsers 권한이 설정에 남아 있어도 공개 요청을 차단할 수 있지만, 기존 IAM 정책과 ACL 자체를 자동으로 지우지는 않습니다. AWS S3의 Block Public Access도 기존 정책과 ACL을 수정하지 않으며, 해당 설정을 해제하면 그 권한이 다시 적용될 수 있습니다. Azure에서도 계정의 익명 접근 허용을 끄면 컨테이너 설정을 재정의해 익명 접근을 차단하지만, 정적 웹 사이트 기능은 별도로 확인해야 합니다. 설정을 수정한 뒤에도 원래 권한과 공개 기능을 정리하고 재점검하는 이유입니다.
점검 주기와 결과 기록

신규 저장소 생성, 외부 공유 링크 발급, 조직 이전, 담당자 변경, 서비스 종료 시에는 공개 설정을 다시 살펴보세요. 정기 점검 주기는 데이터 민감도와 변경 빈도에 맞춰 정하고, 공개가 승인된 저장소도 예외 사유와 검토 시점을 기록합니다. 자동화된 보안 도구의 결과는 우선순위를 정하는 데 유용하지만, 공개 용도와 업무 영향을 확인하는 책임자 검토를 함께 두는 것이 좋습니다.
점검 기록에는 저장소 식별자, 공개 주체, 대상 파일 범위, 읽기·편집 권한, 링크 만료 여부, 조치 결과, 재검증 결과를 남기면 후속 담당자가 변경 맥락을 파악하기 쉽습니다. 공개가 필요한 저장소는 민감 자료를 함께 두지 않고 별도 분리하는 방안도 검토하세요.
자주 묻는 질문
Q. 링크를 알고 있으면 열리는 파일은 모두 공개인가요?
로그인이나 사용자 지정 없이 링크만으로 접근할 수 있다면 공개 범위가 넓은 공유일 수 있습니다. 링크 설정에서 대상이 ‘모든 사용자’인지 특정 계정인지 확인하고, 만료일과 보기·편집 권한도 함께 살펴보세요.
Q. 공개 차단을 켜면 기존 공개 권한도 삭제되나요?
서비스별로 다릅니다. 일부 차단 설정은 공개 요청을 거부하지만 기존 정책이나 ACL을 그대로 보유할 수 있습니다. 차단 적용 여부와 별개로 공개 권한 자체를 점검하고 불필요한 항목을 정리하세요.
Q. 파일이 공개인지 가장 간단하게 확인하는 방법은 무엇인가요?
콘솔의 공개 접근 진단 기능과 파일별 공유 관리 화면을 확인한 뒤, 공개 URL은 로그아웃 상태에서도 검증하세요. 단, 임시 서명 URL처럼 기간과 권한이 제한된 링크는 일반 공개 링크와 다르므로 유형과 만료 조건을 구분해야 합니다.
Q. 업무상 공개해야 하는 파일은 어떻게 관리하나요?
공개 목적에 필요한 파일만 별도 저장소나 경로에 두고, 읽기 권한만 부여하는 방식부터 검토하세요. 소유자와 공개 사유, 점검 시점을 기록하고 개인 정보나 비공개 업무 자료가 함께 올라가지 않았는지 확인합니다.
참고자료
- Amazon S3 스토리지에 대한 퍼블릭 액세스 차단 – AWS Documentation
- IAM Access Analyzer for S3를 사용하여 버킷 액세스 검토 – AWS Documentation
- 공개 액세스 방지 | Cloud Storage | Google Cloud 문서
- 컨테이너 및 Blob에 대한 익명 읽기 권한 구성 – Azure Storage | Microsoft Learn
- Azure Blob Storage 보안 문서 – Microsoft Learn
- Microsoft OneDrive에서 파일 및 폴더 공유 – Microsoft Support
