간단한 3단계로 AWS S3 버킷 내에서 액세스 권한 오케스트레이션을 자동화하는 방법

AWS S3 버킷 내 액세스 권한 자동화 방법

과거 온프레미스 Unix 서버와 대용량 파일 시스템이 대세였던 시절, 기업들은 여러 폴더에 대한 접근 권한을 제어하기 위해 복잡한 폴더 관리 규칙과 전략을 수립했습니다.

일반적으로 조직의 플랫폼은 각기 다른 관심사, 기밀 유지 수준 요구 사항 또는 콘텐츠 유형을 가진 다양한 사용자 그룹에 서비스를 제공합니다. 글로벌 조직의 경우, 이는 지리적 위치에 따라 콘텐츠를 분리하거나, 즉 서로 다른 국가의 사용자들이 서로의 콘텐츠에 접근하지 못하도록 하는 것을 의미할 수 있습니다.

다른 일반적인 예는 다음과 같습니다:

  • 개발, 테스트 및 프로덕션 환경 간의 데이터 분리
  • 특정 그룹만 접근할 수 있는 영업 자료
  • 특정 지역 내에서만 열람하거나 접근할 수 있는 국가별 법률 관련 콘텐츠
  • 제한된 사용자에게만 제공되는 “리더십 데이터”와 같은 프로젝트 관련 자료

이러한 예시는 무궁무진합니다. 핵심은 플랫폼이 서비스를 제공하는 모든 사용자 사이에서 파일 및 데이터 접근 권한을 조정해야 할 필요성이 항상 존재한다는 것입니다.

온프레미스 환경에서는 이것이 일상적인 업무였습니다. 파일 시스템 관리자는 특정 규칙을 설정하고, 적절한 도구를 선택한 다음, 사용자를 사용자 그룹에 매핑하고, 사용자 그룹을 접근 가능한 폴더 또는 마운트 지점에 연결했습니다. 이러한 과정에서 접근 수준은 읽기 전용 또는 읽기/쓰기 권한으로 정의되었습니다.

이제 AWS 클라우드 플랫폼을 고려해 볼 때, 사용자들이 콘텐츠 접근 제한에 대한 비슷한 요구 사항을 가질 것이라는 것은 당연합니다. 하지만 이 문제에 대한 해결책은 이전과는 달라야 합니다. 파일은 더 이상 Unix 서버에 있지 않고 클라우드에 있으며(전 세계에서 접근 가능할 가능성이 있음), 콘텐츠는 폴더가 아닌 S3 버킷에 저장됩니다.

다음은 이 문제에 대한 몇 가지 대안적 접근 방식입니다. 이는 특정 프로젝트에서 이러한 솔루션을 설계하면서 얻은 실제 경험을 바탕으로 합니다.

단순하지만 광범위한 수동 접근

자동화 없이 이 문제를 해결하는 한 가지 방법은 비교적 단순하고 직관적입니다:

  • 각 사용자 그룹마다 새로운 버킷을 생성합니다.
  • 특정 그룹만 S3 버킷에 접근할 수 있도록 접근 권한을 할당합니다.

요구 사항이 매우 단순하고 빠른 해결이 필요할 경우 이는 확실히 실행 가능한 방법입니다. 하지만 몇 가지 제한 사항을 인지해야 합니다.

기본적으로 AWS 계정 하나당 최대 100개의 S3 버킷만 생성할 수 있습니다. AWS 지원 티켓을 통해 서비스 한도 증가를 요청하여 이 제한을 1000개까지 확장할 수 있습니다. 이러한 제한이 특정 구현 시나리오에서 문제가 되지 않는다면, 각 도메인 사용자가 별도의 S3 버킷에서 작업하도록 허용하고 이 방법을 채택할 수 있습니다.

하지만 여러 기능을 수행하는 사용자 그룹이 있거나, 여러 도메인의 콘텐츠에 동시에 접근해야 하는 사용자가 있을 경우 문제가 발생할 수 있습니다. 예를 들면 다음과 같습니다:

  • 여러 영역, 지역 등의 데이터 콘텐츠를 분석하는 데이터 분석가
  • 여러 개발팀에 서비스를 제공하는 테스트 팀
  • 동일한 지역 내 여러 국가에 대한 대시보드 분석을 구축해야 하는 사용자

상상할 수 있듯이, 이러한 목록은 계속 늘어날 수 있으며, 조직의 요구 사항에 따라 다양한 사용 사례가 발생할 수 있습니다.

이 목록이 복잡해질수록, 조직 내 여러 S3 버킷에 대한 접근 권한을 다양한 그룹에 부여하기 위해서는 더욱 정교한 접근 권한 조정이 필요해집니다. 추가 도구가 필요할 수 있으며, 전담 관리자가 접근 권한 목록을 유지 관리하고 변경 사항이 요청될 때마다 업데이트해야 할 수도 있습니다(특히 대규모 조직에서는 빈번하게 발생합니다).

그렇다면 좀 더 체계적이고 자동화된 방식으로 동일한 작업을 수행하는 방법은 무엇일까요?

도메인별 버킷 접근 방식이 효과적이지 않다면, 다른 해결책은 여러 사용자 그룹이 공유하는 버킷을 사용하는 것입니다. 이 경우, 동적으로 변경하거나 업데이트하기 쉬운 영역에서 접근 권한을 할당하는 전체적인 논리를 구축해야 합니다.

이를 달성하는 한 가지 방법은 S3 버킷에서 태그를 활용하는 것입니다. 어떤 경우든 태그를 사용하는 것이 좋습니다(단순한 청구 분류를 위해서라도). 또한 언제든지 모든 버킷의 태그를 변경할 수 있습니다.

전체적인 논리가 버킷 태그를 기반으로 구축되고, 나머지 구성 요소가 태그 값에 따라 설정된다면, 태그 값을 업데이트하는 것만으로 버킷의 목적을 재정의할 수 있으므로 동적인 속성을 보장할 수 있습니다.

어떤 종류의 태그를 사용해야 할까요?

이는 구체적인 사용 사례에 따라 다릅니다. 예를 들면 다음과 같습니다:

  • 환경 유형별로 버킷을 분리해야 할 수 있습니다. 이 경우, 태그 이름 중 하나는 “ENV”가 될 수 있으며, 가능한 값은 “DEV”, “TEST”, “PROD” 등이 될 수 있습니다.
  • 국가별로 팀을 분리할 수도 있습니다. 이 경우, 다른 태그는 “COUNTRY”가 되며, 다양한 국가 이름을 값으로 가집니다.
  • 또는 비즈니스 분석가, 데이터 웨어하우스 사용자, 데이터 과학자 등 사용자가 속한 기능 부서에 따라 사용자를 구분할 수도 있습니다. 따라서 “USER_TYPE”이라는 태그와 해당 값들을 생성합니다.
  • 다른 방법으로는, 특정 사용자 그룹에 대해 미리 정의된 폴더 구조를 명시적으로 정의할 수 있습니다(자체 폴더를 생성하지 않고 시간이 지남에 따라 사라지지 않도록). “data/import”, “data/processed”, “data/error” 등과 같은 여러 작업 디렉토리를 지정할 수 있는 태그를 사용하여 이를 수행할 수 있습니다.

이상적으로는 태그를 논리적으로 결합하여 버킷 내에서 전체 폴더 구조를 만들 수 있어야 합니다.

예를 들어, 위 예시에서 다음과 같은 태그를 결합하여 다양한 국가의 다양한 사용자 유형을 위한 전용 폴더 구조를 구성할 수 있습니다. 미리 정의된 가져오기 폴더를 사용하는 경우입니다.

  • //<사용자 유형>/<국가>/<업로드>

태그의 용도는 값만 변경하여 재정의할 수 있습니다(테스트 환경, 개발 환경, 프로덕션 환경 등에 할당할지 여부).

이를 통해 여러 사용자가 동일한 버킷을 사용할 수 있습니다. 버킷은 명시적으로 폴더를 지원하지 않지만, “레이블”을 지원합니다. 이러한 레이블은 사용자가 데이터에 접근하기 위해 일련의 레이블을 거쳐야 하므로, 하위 폴더처럼 작동합니다(하위 폴더와 마찬가지로).

사용 가능한 형식으로 태그를 정의한 후 다음 단계는 태그를 활용하는 S3 버킷 정책을 구축하는 것입니다.

정책이 태그 이름을 사용하는 경우, 이를 “동적 정책”이라고 합니다. 이는 기본적으로 정책이 특정 형태나 자리 표시자를 참조하는 태그 값에 따라 다른 버킷에서 다르게 동작한다는 것을 의미합니다.

이 단계에는 동적 정책을 위한 일부 사용자 정의 코딩이 포함되지만, Amazon AWS 정책 편집기 도구를 사용하여 프로세스를 간소화할 수 있습니다.

정책 자체 내에서 버킷에 적용할 특정 접근 권한과 해당 권한의 수준(읽기, 쓰기)을 정의합니다. 논리는 버킷의 태그를 읽고 버킷 내에 폴더 구조를 구축합니다(태그를 기반으로 레이블 생성). 태그의 특정 값을 기반으로 하위 폴더가 생성되고 필요한 접근 권한이 지정됩니다.

이러한 동적 정책의 장점은 한 번만 생성한 다음 여러 버킷에 할당할 수 있다는 것입니다. 정책은 태그 값이 다른 버킷에서 다르게 동작하지만, 항상 태그 값이 있는 버킷에 대한 기대치와 일치합니다.

이는 많은 버킷에 대한 접근 권한 할당을 체계적이고 중앙 집중식 방식으로 관리하는 효과적인 방법입니다. 여기서 모든 버킷은 미리 합의된 템플릿 구조를 따르고 사용자들이 조직 전체에서 내부적으로 사용할 것으로 예상됩니다.

새로운 엔티티의 온보딩 자동화

동적 정책을 정의하고 기존 버킷에 할당한 후에는 다른 사용자 그룹이 자신이 접근할 수 없는 폴더 구조에 있는 콘텐츠(동일한 버킷에 저장됨)에 접근할 위험 없이 동일한 버킷을 사용할 수 있습니다.

또한, 접근 권한이 더 넓은 일부 사용자 그룹의 경우 데이터가 모두 동일한 버킷에 저장되므로 데이터에 쉽게 접근할 수 있습니다.

마지막 단계는 새로운 사용자, 새로운 버킷, 새로운 태그를 최대한 쉽게 온보딩하는 것입니다. 이는 추가적인 사용자 정의 코딩이 필요하지만, 온보딩 프로세스에 간단하고 명확한 알고리즘 논리로 캡슐화할 수 있는 명확한 규칙이 있다고 가정하면 지나치게 복잡할 필요가 없습니다(적어도 프로세스에 어느 정도의 논리가 있으며 무질서하게 수행되지 않습니다).

이는 새로운 엔티티를 플랫폼에 성공적으로 온보딩하는 데 필요한 매개변수를 사용하여 AWS CLI 명령으로 실행 가능한 스크립트를 생성하는 것만큼 간단할 수 있습니다. 예를 들어 다음과 같이 특정 순서로 실행 가능한 일련의 CLI 스크립트가 될 수 있습니다.

  • create_new_bucket(,,<국가>,<국가_값>, ..)
  • create_new_tag(,,)
  • update_existing_tag(,,)
  • create_user_group(<사용자 유형>,<국가>,)

요점을 이해하실 겁니다. 😃

전문가 팁 👨‍💻

원하는 경우 위에 쉽게 적용할 수 있는 전문가 팁이 있습니다.

동적 정책은 폴더 위치에 대한 접근 권한 할당뿐만 아니라, 버킷 및 사용자 그룹에 대한 서비스 권한을 자동으로 할당하는 데에도 활용할 수 있습니다!

필요한 것은 버킷의 태그 목록을 확장한 다음 특정 사용자 그룹에 대해 특정 서비스를 사용하기 위한 동적 정책 접근 권한을 추가하는 것입니다.

예를 들어, 특정 데이터베이스 클러스터 서버에도 접근해야 하는 사용자 그룹이 있을 수 있습니다. 이는 의심할 여지 없이 버킷 작업을 활용하는 동적 정책을 통해 달성할 수 있으며, 서비스에 대한 접근이 역할 기반 방식으로 관리된다면 더욱 그렇습니다. 동적 정책 코드에 데이터베이스 클러스터 사양에 대한 태그를 처리하는 부분을 추가하고 해당 DB 클러스터와 사용자 그룹에 직접 정책 접근 권한을 부여하면 됩니다.

이렇게 하면 이 단일 동적 정책만으로 새로운 사용자 그룹의 온보딩을 실행할 수 있습니다. 또한 동적이기 때문에 동일한 정책을 다양한 사용자 그룹 온보딩에 재사용할 수 있습니다(동일한 템플릿을 따르지만, 반드시 동일한 서비스를 사용하지 않을 수도 있음).

버킷과 데이터를 관리하기 위해 이러한 AWS S3 명령을 살펴볼 수도 있습니다.