IAM Policy 종류에 따른 JSON 구조
IAM 정책은 사용자에게 부여해서 사용자가 AWS 서비스에 엑세스 하는 구조를 가지지만, 사용자 뿐만 아니라 어플리케이션(리소스)에도 적용할수가 있다.
예를들어 EC2 인스턴스를 마치 유저 처럼 권한 부여가 가능하다. 따라서 사용자에게 적용하느냐, 어플리케이션에 적용하느냐에 따라 Policy 타입이 나뉘게 된다.
IAM 정책이라는 것은 "누가(Principal, 행동주체) 어떤 특정 조건 (Condition)을 만족할 때 어떤 특정 대상(Resource)에 대해 어떠한 행위(Action)를 할 수 있게 허용/불허(Effect)한다."라는 의미를 담은 것이다.
그런데 정책에서 주어 역할을 하는 Principal 속성은 정책 타입에 따라서 쓰기도 하고 안쓰기도 한다.
자격증명 기반 정책(Id-Based Policy)
AWS 계정, 사용자, 그룹, 역할 등이 주체가 되어 수행할 수 있는 작업, 리소스 및 조건을 제어하는 정책이다. IAM 정책에서 조회되는 정책 대부분이 자격 증명 기반 정책이다.
정책에 연결된 사용자가 곧 보안주체(Principal)가 되므로 Statement 에서 Principal 을 따로 기재하지 않는다는 특징이 있다.
정책에 연결된 보안 주체(AWS 계정, IAM 사용자, 그룹, 역할 등)가 암묵적인 Principal이 되기 때문이다. 그래서 실제로 자격 증명 기반 정책의 JSON 구조를 보면 Principal 속성이 생략되어 있다.
쉽게 말하면 이 정책과 연결된 보안주체는 어떤 대상에 대해 이러한 권한이 부여된다 라는 의미이고 정책을 부여한 보안주체가 곧 유저가 되니 굳이 Principal(보안주체) 속성이 필요가 없는 것이다.
IAM Policy 메뉴에서 또는 IAM Role에 인라인으로 관리한다. 모든 AWS 서비스에 연관된다.
리소스 기반 정책(Resource-Based Policy)
자격 증명 기반 정책이 사람(유저)에게 연결하는 정책이었다면, 리소스 기반 정책은 AWS 리소스에 연결하는 정책이다.
AWS의 리소스 중에서 일부 서비스에서 사용되며 대표적으로 S3에서 사용되는 S3 버킷 정책이 대표적이다.
반드시 Principal 속성을 기재해야 하는데 AWS 리소스에게 적용되는것이기 때문에 이러한 대상(Resource)에 대해 이러한 행위를(Action) 할 수 있는 권한이 누구누구(Principal)에게 부여한다 라는 뜻이 된다. 즉, 이 누구누구를 Principal 속성을 통해 필수적으로 지정해주어야 된다는 말이다.
일부 AWS 서비스의 리소스에서 자체 관리(대표적으로 S3, SQS 등) 하며 일부 공유 자원 성격을 가진 서비스에서 사용한다.
JSON 정책 요소
---Statement 엘리먼트 요소---
SID (string) : Statement ID로 statement 를 구분하기 위해서 사용 (옵셔널)
Effect : 엑세스를 허용하는지 거부하는지 설정. (Allow / Deny)
Principal / NotPrincipal : 엑세스를 허용하거나 거부할 대상(사용자, 역할 등)을 지정
Action / NotAction (string | array)
서비스의 API Calls를 지정한다.
하나 혹은 여러 개의 Action을 지정할 수 있다.
각 서비스별로 고유의 서비스 접두사(예: DynamoDB는 dynamodb, S3는 s3)가 있다.
Action은 (서비스 접두사):(작업) 형식으로 작성 → dynamodb:DeleteItem, s3:GetObject
Resource, NotResource
Action이 영향을 미치는 리소스 리스트를 지정한다.
리소스 기반 정책을 생성하는 경우 선택 사항이다. 이 요소를 포함하지 않으면 작업이 적용되는 리소스는 정책이 연결된 리소스 이다.
리소스를 특정할 수 없는 일부 서비스에서는, Resource를 비워두는 대신 와일드카드* 를 설정한다.
ARN을 사용하여 리소스를 지정한다.
Condition (object)
조건을 넣어 줄 수 있다. 즉, 조건을 충족되는 경우에만 해당 정책을 적용시킬 수 있는 개념
NumericEquals 일치
NumericNotEquals 불일치
NumericLessThan "미만" 일치
NumericLessThanEquals "이하" 일치
NumericGreaterThan "초과" 일치
NumericGreaterThanEquals "이상" 일치
예) "Statement": { "Condition": {"NumericLessThanEquals": {"s3:max-keys": "10"}}}
자격증명 기반 정책에서 condition 에 충족하지 않는 사용자 라도 권한 추가는 가능하지만 해당 권한을 행사할 수 는 없다.
예를들어 아래와 같은 정책이 있을 때 사용자 arn이 다른 사용자라도 해당 정책을 권한에 추가할 수는 있으나 s3:GetObject 행위를 할 수 있는 권한은 없다.
"Statement": {
"Action" : [ "s3:GetObject" ],
"Condition": { "StringEquals": { "aws:PrincipalArn": "arn:aws:iam::637423653081:user/test" } }
}
AWS CodeCommit에 대한 HTTPS Git 자격 증명
자격증명을 생성하고 처음 CodeCommit 에 연결시 Git credential Manager 팝업창이 생성되어 자격 증명 생성을 통해 받은 User Name,Password 를 입력해야 한다.
한번 CodeCommit에 연결 후 윈도우 기준 '자격 증명 관리자' 에서 캐시 데이터로 저장되기 때문에 이후 연결부터는 User Name,Password 를 입력할 필요가 없다.
캐시 데이터를 확인하려면 '자격 증명 관리자' 에서 'Windows 자격 증명'을 클릭하면 출력되는 리스트에서 확인이 가능하다.
기존 자격 증명을 삭제하고 새로 생성한 경우 자격 증명 관리자 에서 이전 자격 증명 캐시 데이터를 삭제 해야만 CodeCommit 과 정상적으로 통신이 가능하다.
아닐 경우 The requested URL returned error: 403 에러가 발생한다.
