AWS IAM 정책 오류, 실무에서 자주 발생하는 유형별 분석 및 해결 가이드
IAM 정책 오류, 왜 실무에서 자주 발생할까?
AWS IAM(Identity and Access Management) 정책은 클라우드 환경의 보안과 접근 제어를 위한 핵심 요소입니다. 하지만 실제 운영 환경에서는 AWS IAM 정책 오류가 빈번하게 발생하며, 이는 서비스 중단이나 심각한 보안 취약점으로 이어질 수 있습니다. 이러한 오류는 주로 복잡성, 잘못된 설정, 지속적인 관리 부족 등 몇 가지 주요 원인에서 비롯됩니다.
IAM 정책 오류의 주요 발생 원인
- 복잡성으로 인한 이해 부족: IAM 정책은 JSON 형식으로 작성되며, 조건, 변수, ARN 등 다양한 요소를 포함합니다. 이 때문에 정책이 실제로 어떻게 작동하는지 정확히 파악하기 어려울 수 있습니다. 특히 와일드카드(*)를 잘못 사용하거나 리소스 ARN을 부정확하게 지정하면 예상치 못한 권한 문제가 발생할 수 있습니다.
- 권한 과다 부여 (Over-privilege): '최소 권한 원칙'을 지키지 않고 불필요한 권한까지 부여하는 경우가 흔합니다. 이는 보안 사고가 발생했을 때 피해 범위를 확대시키는 주된 요인이 됩니다.
- 정책 업데이트 누락 또는 오류: 서비스 변경이나 보안 강화 요구에 따라 IAM 정책은 주기적으로 검토하고 업데이트해야 합니다. 이 과정에서 누락되거나 잘못된 수정은 서비스 접근 불가 또는 보안 허점을 초래할 수 있습니다.
- 리소스 ARN의 부정확성: ARN(Amazon Resource Name)이 정확하지 않으면 의도한 리소스에 대한 권한이 제대로 적용되지 않거나, 반대로 원치 않는 리소스에 접근 권한이 부여될 위험이 있습니다.
- 조건(Condition)의 잘못된 사용: 정책 내 조건 설정이 논리적으로 오류가 있거나, 키-값 쌍을 잘못 사용하면 정책이 기대한 대로 작동하지 않을 수 있습니다.
이러한 근본적인 원인들을 명확히 이해하는 것은 AWS IAM 정책 오류를 사전에 방지하고 발생 시 신속하게 해결하는 데 매우 중요합니다. 다음 섹션에서는 실무에서 자주 발생하는 AWS IAM 정책 오류, 실무에서 자주 발생하는 유형별 분석과 함께 효과적인 해결 방안을 자세히 알아보겠습니다.
권한 누락: '액세스 거부'의 가장 흔한 원인
AWS IAM 정책 오류로 인해 '액세스 거부(Access Denied)' 메시지를 마주하는 것은 매우 흔한 일이며, 그중 가장 빈번한 원인은 바로 권한 누락입니다. 이는 사용자가 특정 AWS 리소스에 접근하거나 특정 API 작업을 수행하려 할 때, 해당 작업을 수행하는 데 필요한 권한이 IAM 정책에 명시적으로 부여되지 않아 발생하는 문제입니다. 실무에서 자주 발생하는 유형별 분석을 통해 이 문제를 정확히 이해하는 것이 중요합니다.
1. 필수 권한 누락
가장 기본적인 형태의 권한 누락은 사용자가 수행하려는 작업에 필요한 IAM 액션(Action) 자체가 정책에 포함되지 않은 경우입니다. 예를 들어, S3 버킷에서 객체를 읽으려 하는데 정책에 s3:GetObject 권한이 명시적으로 부여되지 않았다면 '액세스 거부' 오류가 발생합니다. 이러한 경우, CloudTrail 로그를 분석하여 실패한 API 호출을 파악하고 필요한 권한을 IAM 정책에 추가해야 합니다. 또한, AWS IAM Policy Simulator를 활용하여 정책 적용 결과를 미리 테스트해 보는 것이 효과적인 해결책이 될 수 있습니다. **점검 포인트: 수행하려는 작업과 관련된 모든 API 호출에 대한 권한이 정책에 명시적으로 포함되어 있는지 확인하세요.**
2. 잘못된 리소스 지정
권한이 정책에 포함되어 있더라도, 해당 권한이 적용되는 리소스(Resource)가 잘못 지정되었거나 너무 제한적으로 설정된 경우에도 '액세스 거부'가 발생할 수 있습니다. 예를 들어, 특정 S3 버킷에 대한 s3:GetObject 권한을 부여했지만, 정책의 Resource 섹션에서 버킷 이름이나 객체 경로를 잘못 기재했다면 접근이 거부됩니다. 이 경우, 정확한 리소스 ARN을 확인하고 필요한 경우 와일드카드(*)를 적절히 활용하여 리소스 범위를 조정해야 합니다. 때로는 조건(Condition) 절이 의도와 다르게 작동하여 접근을 제한하는 경우도 있으므로, 관련 설정도 함께 면밀히 검토해야 합니다.
과도한 권한 부여: 보안 위험과 비용 증가의 주범
AWS IAM 정책에서 가장 흔하게 발생하는 실수는 불필요하게 넓은 권한을 부여하는 것입니다. 이는 '최소 권한 원칙(Principle of Least Privilege)'을 위배하며, 심각한 보안 위험과 예상치 못한 비용 증가를 초래할 수 있습니다. 이 원칙은 사용자, 역할 또는 서비스가 작업을 수행하는 데 필요한 최소한의 권한만 부여해야 한다는 보안의 근본 원칙입니다.
과도한 권한 부여의 영향
1. 보안 침해 위험 증가: 공격자가 탈취한 자격 증명으로 민감한 데이터에 접근하거나, 리소스를 삭제/수정하거나, 추가적인 악성 행위를 수행할 가능성이 커집니다. 예를 들어, 특정 S3 버킷에 대한 `s3:*`와 같은 와일드카드 권한은 해당 버킷의 모든 데이터를 읽거나 쓸 수 있게 하여 데이터 유출 위험을 높입니다.
2. 비용 증가: 과도한 권한은 의도치 않게 고가의 리소스(예: EC2 인스턴스, RDS 데이터베이스)를 생성하거나, 불필요한 API 호출을 유발하여 예상치 못한 요금을 발생시킬 수 있습니다. 악의적인 사용자가 고성능 EC2 인스턴스를 계속해서 생성하여 과도한 비용을 초래하는 경우가 이에 해당합니다.
3. 운영 복잡성 증대: 광범위한 권한은 정책 관리를 어렵게 만들 뿐만 아니라, 문제 발생 시 원인 파악과 해결 과정을 더욱 복잡하게 만듭니다. 어떤 권한이 실제로 사용되는지 추적하기 어려워 잠재적인 보안 허점을 놓치기 쉽습니다.
개선 방안
1. 최소 권한 원칙 적용: 각 사용자, 그룹, 역할 및 서비스에 필요한 최소한의 권한만 부여해야 합니다. 특정 작업에 필요한 API 작업과 리소스에 대해서만 명시적으로 권한을 정의하는 것이 중요합니다. 예를 들어, 특정 S3 버킷에서 객체를 읽기만 하면 되는 역할에는 `s3:GetObject` 권한만 특정 버킷 ARN에 대해 부여합니다.
2. AWS IAM Access Analyzer 활용: IAM Access Analyzer는 외부 계정이나 IAM 엔티티에서 접근 가능한 리소스에 대한 가시성을 제공합니다. 이를 통해 의도하지 않은 외부 접근 권한이나 과도하게 부여된 내부 권한을 식별하고 수정하는 데 도움을 받을 수 있습니다.
3. IAM 정책 시뮬레이터 활용: IAM 정책 시뮬레이터를 사용하면 특정 사용자 또는 역할에 대해 정책이 실제로 어떤 작업을 허용하거나 거부하는지 테스트할 수 있습니다. 이를 통해 정책이 의도한 대로 작동하는지, 또는 과도한 권한을 포함하고 있는지 사전에 검증하는 것이 효과적입니다.
4. 주기적인 권한 감사: 정기적으로 IAM 정책을 검토하고, 사용되지 않거나 더 이상 필요하지 않은 권한은 제거해야 합니다. AWS CloudTrail 로그를 분석하여 실제 API 호출 기록을 기반으로 권한을 조정하는 것도 좋은 방법입니다.
5. AWS Organizations SCP 활용: AWS Organizations를 사용하는 경우, 서비스 제어 정책(SCP)을 통해 계정 수준에서 허용되는 API 작업의 범위를 제한하여 과도한 권한 부여를 방지할 수 있습니다.
이처럼 과도한 권한 부여는 단순한 실수를 넘어 심각한 보안 사고와 재정적 손실로 이어질 수 있는 주요 위험 요소입니다. 'AWS IAM 정책 오류, 실무에서 자주 발생하는 유형별 분석'을 통해 최소 권한 원칙을 철저히 준수하고, 자동화된 도구를 활용하여 주기적으로 권한을 감사하는 노력이 필수적입니다.
조건(Condition) 오류: 의도치 않은 접근 차단
AWS IAM 정책에서 조건(Condition)은 특정 요구사항이 충족될 때만 권한을 허용하거나 거부하는 중요한 기능입니다. 하지만 이 조건 설정에서 발생하는 사소한 실수 하나가 예상치 못한 접근 제한을 초래하여 서비스 운영에 심각한 문제를 일으킬 수 있습니다. 실무에서 자주 마주치는 조건 오류 유형과 각 상황별 해결책을 자세히 살펴보겠습니다.1. IP 주소 조건 오류
가장 흔하게 접하는 오류는 IP 주소 관련 조건 설정 문제입니다. 예를 들어, 특정 IP 대역만 접근을 허용하려 할 때, 내부 네트워크 IP가 아닌 외부 공인 IP 대역을 잘못 기입하거나 CIDR 표기법을 틀리게 사용하여 의도와 다르게 접근이 차단되는 경우가 빈번합니다. 예시: json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-bucket/*", "Condition": { "IpAddress": { "aws:SourceIp": "192.168.1.0/24" } } } ] } 이 정책은 `192.168.1.0/24` 대역에서만 S3 객체 읽기를 허용하도록 설계되었습니다. 그러나 만약 이 정책이 적용된 IAM 엔티티가 NAT 게이트웨이나 프록시 서버를 경유하여 접근한다면, `aws:SourceIp`는 실제 내부 IP가 아닌 NAT 게이트웨이의 공인 IP로 인식됩니다. 결과적으로, 이 조건은 의도한 대로 작동하지 않거나 오히려 접근을 막는 장애물이 될 수 있습니다. 해결 방안: - 실제 서비스 접근이 발생하는 IP 주소를 정확히 파악하는 것이 우선입니다. VPC 내 EC2 인스턴스가 S3에 접근하는 경우, VPC 엔드포인트를 활용하거나 NAT 게이트웨이의 공인 IP를 조건에 포함시키는 방안을 고려해야 합니다. - `aws:SourceVpc` 또는 `aws:SourceVpce` 조건을 사용하여 VPC 또는 VPC 엔드포인트를 통한 접근을 명시적으로 허용하는 것이 보안과 안정성 측면에서 더욱 권장됩니다.2. 시간 조건 오류
`aws:CurrentTime` 조건을 사용하여 특정 시간대에만 접근을 허용하거나 제한하는 경우에도 설정 오류가 발생하기 쉽습니다. 가장 큰 원인은 시간대(Timezone) 설정을 간과하거나, UTC 기준 시간을 잘못 이해하여 발생하는 문제입니다. 예시: json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:StartInstances", "Resource": "*", "Condition": { "DateLessThan": { "aws:CurrentTime": "2023-10-27T09:00:00Z" } } } ] } 위 정책은 UTC 기준으로 2023년 10월 27일 오전 9시 이전까지만 EC2 인스턴스 시작을 허용합니다. 만약 운영팀이 한국 시간(KST, UTC+9)으로 오전 9시까지 작업을 계획했다면, UTC 기준으로는 이미 오후 6시가 지나 접근이 차단되는 상황이 발생합니다. 해결 방안: - `aws:CurrentTime` 조건은 항상 UTC 기준으로 작동한다는 점을 명확히 인지해야 합니다. - 필요한 경우, `aws:CurrentTime` 조건과 함께 `aws:RequestedRegion` 조건을 조합하여 특정 지역의 시간대를 고려하거나, AWS Lambda, EventBridge와 같은 별도의 스케줄링 도구를 활용하여 시간 기반 접근 제어를 구현하는 것이 더 효과적입니다.3. MFA 조건 오류
다단계 인증(MFA)을 요구하는 조건(`aws:MultiFactorAuthPresent`) 설정 오류는 보안 강화라는 본래 목적과 달리 오히려 접근 불가 상황을 야기할 수 있습니다. MFA 장치가 등록되지 않은 사용자가 있거나, IAM 엔티티가 MFA 없이 접근하는 경우를 잘못 판단하여 발생하는 문제입니다. 해결 방안: - MFA 조건은 IAM 사용자가 MFA 장치를 통해 인증했는지 여부를 확인하는 데 사용됩니다. - MFA를 요구하는 정책을 적용하기 전에, 모든 관련 IAM 사용자가 MFA 장치를 성공적으로 등록하고 사용할 수 있는지 충분한 테스트를 수행해야 합니다. - MFA를 사용하지 않는 서비스 계정이나 애플리케이션 접근에는 이 조건을 포함하지 않도록 신중하게 접근해야 합니다.AWS IAM 정책 오류 디버깅 팁
- **IAM Policy Simulator 활용:** AWS IAM Policy Simulator는 정책이 실제로 어떻게 동작하는지 시뮬레이션하고 디버깅하는 데 매우 유용한 도구입니다. 조건이 예상대로 작동하는지, 혹은 특정 상황에서 접근이 거부되는 이유를 명확하게 파악할 수 있습니다. - **CloudTrail 로그 분석:** AWS CloudTrail 로그는 IAM 활동에 대한 상세한 기록을 제공합니다. 접근 거부 이벤트가 발생했을 때, 해당 이벤트의 `errorCode`와 `errorMessage`를 분석하면 조건 오류의 근본 원인을 찾는 데 큰 도움이 됩니다. 특히 `AccessDenied` 관련 로그를 주의 깊게 살펴보는 것이 좋습니다. - **최소 권한 원칙 준수:** 처음부터 너무 광범위한 조건을 설정하기보다는, 반드시 필요한 최소한의 권한과 조건만 부여하고 점진적으로 필요한 권한을 확장해 나가는 것이 오류 발생 가능성을 크게 줄이는 현명한 방법입니다. 이처럼 조건 오류는 복잡하게 느껴질 수 있지만, 각 조건의 정확한 작동 방식을 이해하고 실제 운영 환경을 고려한 철저한 테스트와 디버깅 과정을 거친다면 충분히 효과적으로 관리하고 해결할 수 있습니다.정책 구문 오류 및 JSON 유효성 문제
AWS IAM 정책은 JSON(JavaScript Object Notation) 형식으로 작성되므로, JSON 구문 자체의 오류나 잘못된 문법은 정책 적용 실패로 이어지는 주된 원인입니다. 이러한 AWS IAM 정책 오류는 실무에서 빈번하게 발생하며, 유형별로 분석하여 대비하는 것이 중요합니다. 여기서는 구문 관련 오류 유형과 해결 방안을 자세히 살펴보겠습니다.
JSON 형식 오류
가장 흔하게 발생하는 문제는 JSON의 기본 형식을 제대로 따르지 않는 경우입니다. { }, [ ], " ", , 등의 구분 기호가 누락되거나 잘못 사용되면 정책 해석에 문제가 생깁니다. IAM 정책은 키-값 쌍으로 구성되며, 여러 요소를 포함할 때는 쉼표(,)로 구분해야 합니다. 또한, 모든 문자열은 반드시 큰따옴표로 감싸야 합니다. 예를 들어, "Effect": Allow와 같이 값에 따옴표를 사용하지 않으면 오류가 발생하니 주의해야 합니다.
IAM 정책 문법 오류
JSON 형식이 올바르더라도 IAM 정책 자체의 문법적인 오류가 있을 수 있습니다. Version, Statement, Effect, Action, Resource 등 IAM 정책에서 사용하는 필수 요소들의 철자가 틀렸거나, 필요한 요소가 빠져 있거나, 혹은 잘못된 값을 사용하는 경우가 이에 해당합니다. 특히 "Effect": "Allow" 대신 "Effect": "allow"와 같이 대소문자를 잘못 사용하는 것도 흔한 오류 중 하나입니다.
유효성 검증 도구 활용
이러한 구문 및 문법 오류를 사전에 방지하고 신속하게 탐지하려면 검증 도구를 적극적으로 활용하는 것이 필수적입니다. AWS Management Console의 **AWS Policy Generator**는 GUI 환경에서 정책을 쉽게 생성할 수 있도록 지원하며, 동시에 자동 유효성 검사를 수행하여 오류를 줄여줍니다. 또한, JSONLint와 같은 온라인 JSON 검사기를 활용하면 JSON 형식의 정확성을 빠르게 확인할 수 있습니다. 코드로 정책을 관리하는 경우, AWS CLI나 SDK를 통해 정책을 생성하거나 업데이트할 때 유효성 검사가 자동으로 이루어지며, 오류 발생 시 명확한 메시지를 통해 문제점을 파악하는 데 도움을 줍니다. 더불어, **IAM Policy Simulator**를 사용하여 정책이 실제로 어떻게 작동하는지 테스트하면, 구문 오류는 아니지만 의도와 다르게 권한이 부여되거나 거부되는 논리적 오류까지 발견하는 데 큰 도움이 됩니다. 이처럼 다양한 도구를 활용하여 AWS IAM 정책 오류를 최소화하는 것이 중요합니다.
IAM 정책 오류 예방 및 관리 전략
AWS IAM 정책 오류는 사소한 설정 실수 하나로도 심각한 보안 취약점을 초래하거나 서비스 운영에 차질을 빚을 수 있습니다. 따라서 오류 발생 가능성을 사전에 차단하고, 문제가 생겼을 때 신속하게 해결할 수 있는 체계적인 관리 전략을 수립하는 것이 무엇보다 중요합니다.1. 정기적인 감사 및 검토
클라우드 환경은 끊임없이 변화하므로 IAM 정책 또한 이에 맞춰 지속적으로 검토하고 업데이트해야 합니다. 이를 위해 정기적인 감사 및 검토 절차를 마련하는 것이 필수적입니다. * **최소 권한 원칙 준수 여부 확인:** 각 사용자, 그룹, 역할에 부여된 권한이 해당 업무 수행에 반드시 필요한 최소한의 수준인지 정기적으로 점검해야 합니다. 지나치게 넓은 권한은 예상치 못한 보안 위험을 증폭시킬 수 있습니다. * **불필요한 권한 제거:** 현재 사용되지 않거나 중복되는 권한은 과감히 삭제하여 정책을 간결하고 명확하게 유지합니다. * **정책 적용 전 영향 분석:** 새로운 정책을 도입하거나 기존 정책을 수정하기 전에, 해당 변경이 어떤 리소스와 서비스에 영향을 미칠지 사전에 면밀히 분석하는 습관을 들입니다. AWS IAM Access Analyzer와 같은 도구를 활용하면 이러한 분석을 효율적으로 수행할 수 있습니다.2. 자동화된 검증 도구 활용
사람의 눈으로 모든 정책 오류를 완벽하게 찾아내기란 현실적으로 어렵습니다. 자동화된 검증 도구를 적극적으로 활용하여 정책의 유효성과 보안성을 체계적으로 검증하는 것이 효과적입니다. * **IAM 정책 시뮬레이터 활용:** AWS IAM 콘솔에서 제공하는 정책 시뮬레이터를 통해 특정 사용자나 역할이 특정 작업을 수행할 권한을 가지고 있는지 미리 테스트해볼 수 있습니다. * **IAM Access Analyzer 활용:** IAM Access Analyzer는 외부 계정이나 공개적으로 접근 가능한 리소스에 대한 접근 권한을 허용하는 정책을 자동으로 식별하고 경고를 제공하여 보안 강화에 도움을 줍니다. * **타사 보안 도구 통합:** 다양한 상용 및 오픈소스 도구들은 IAM 정책의 복잡성, 잠재적 보안 취약점, 규정 준수 여부를 심층적으로 분석하는 기능을 제공합니다. 이러한 도구들을 CI/CD 파이프라인에 통합하여 코드 변경 시 자동으로 정책을 검증하는 방안을 고려해볼 수 있습니다.3. 지속적인 교육 및 인식 개선
많은 IAM 정책 오류는 개발자나 운영자가 IAM의 중요성과 올바른 사용법에 대한 이해가 부족한 상태에서 발생하는 경우가 많습니다. 따라서 팀원 전체를 대상으로 IAM 정책의 핵심 원칙과 모범 사례에 대한 꾸준한 교육을 제공하는 것이 중요합니다. * **IAM 핵심 개념 교육:** 최소 권한 원칙, 정책 구성 요소(Effect, Action, Resource, Condition), ARN(Amazon Resource Name) 등 IAM의 기본 개념에 대한 이해도를 높입니다. * **실무 사례 기반 학습:** 성공적인 IAM 정책 관리 사례뿐만 아니라, 실제 발생했던 오류 사례를 공유하며 팀원들이 실질적인 학습 경험을 쌓도록 유도합니다. 예를 들어, "AWS IAM 정책 오류, 실무에서 자주 발생하는 유형별 분석"과 같은 자료를 활용하여 구체적인 상황별 대처 방안을 논의할 수 있습니다. * **정책 검토 프로세스 참여 독려:** 정책 변경 시 동료 검토(Peer Review) 프로세스에 팀원들이 적극적으로 참여하도록 장려하여, 공동의 책임감을 갖고 더욱 견고한 정책을 만들어나가도록 합니다. 이러한 예방 및 관리 전략을 꾸준히 실천한다면 IAM 정책 오류 발생 가능성을 획기적으로 줄이고, 만약 오류가 발생하더라도 신속하게 대응하여 안정적이고 안전한 AWS 환경을 유지할 수 있습니다.경험에서 배운 점
AWS IAM 정책 오류는 엔터프라이즈 환경에서 빈번하게 발생하는 문제입니다. 특히 '권한 부족(Access Denied)' 오류는 개발팀과 운영팀 모두에게 상당한 부담을 안겨주며, 문제 해결에 많은 시간을 허비하게 만듭니다. 저희 팀은 이러한 유형의 오류가 반복적으로 발생하는 것을 목격했으며, 이를 해결하고 재발을 방지하기 위한 몇 가지 실무적인 교훈을 얻었습니다.
가장 빈번한 오류는 '최소 권한 원칙'을 간과한 정책 설정에서 비롯됩니다. 개발팀에서 특정 서비스에 대한 접근 권한을 요청할 때, 해당 서비스가 필요로 하는 최소한의 권한만을 부여해야 함에도 불구하고, 종종 모든 권한(예: s3:*)을 부여하는 사례가 발생합니다. 이는 보안 취약점을 초래할 뿐만 아니라, 의도치 않은 리소스 변경이나 삭제로 이어질 수 있습니다. 이러한 문제를 예방하려면, 정책 검토 시 '이 권한이 정말 필요한가?'라는 질문을 항상 염두에 두고, 구체적인 API 액션과 리소스 ARN을 명시적으로 지정하는 습관을 들이는 것이 중요합니다. 더불어, AWS IAM Access Analyzer와 같은 도구를 적극 활용하여 불필요하거나 과도한 권한 설정을 주기적으로 감사하는 것이 필수적입니다.
또 다른 흔한 오류는 정책의 적용 범위(Scope)를 잘못 이해하는 경우입니다. 예를 들어, IAM 역할에 연결된 정책이 특정 리소스에 대한 접근만 허용하도록 설정했음에도 불구하고, 해당 역할을 사용하는 EC2 인스턴스가 다른 리소스에 접근하려 할 때 오류가 발생하는 식입니다. 이는 IAM 정책이 역할 자체에 적용되는 것이 아니라, 해당 역할을 사용하는 주체(사용자, 애플리케이션 등)에게 권한을 부여한다는 점을 간과했기 때문입니다. 이러한 혼란을 줄이기 위해, 저희는 IAM 정책 작성 시 '누가(Who) 어떤 리소스(What)에 대해 어떤 액션(Action)을 할 수 있는가'를 명확히 정의하고, 정책이 적용되는 주체와 대상 리소스를 명확하게 문서화하는 프로세스를 구축했습니다. 더불어, 정책 시뮬레이터(Policy Simulator)를 활용하여 실제 적용 전에 예상되는 권한 부여 결과를 미리 확인하는 습관을 들이는 것이 실수를 줄이는 데 큰 도움이 됩니다. 실제로, 저희 팀은 정책 시뮬레이터를 통해 S3 버킷에 대한 특정 파일만 수정할 수 있는 권한을 부여하는 정책을 테스트하여, 불필요한 권한 부여 가능성을 사전에 차단한 경험이 있습니다.
댓글
댓글 쓰기