몇 년 전 대용량 파일 시스템이 있는 온프레미스 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 명령을 살펴볼 수도 있습니다.