Policy
AWS IAM 정책은 5가지 형태의 구조를 가지고 있다.
- Effect
- Principal
- Resources
- Action
- Condition
누가(Principal) 대상(Resources)에 작업(Action)을 조건(Condition)에 따라 허용(Effect)할지 말지를 정해 놓은 정책이다. 이 정책이 적용할 대상은 Identity 가 될 수도 resource 가 될 수도 있다.
Identity 기반 정책
누가(Principal) 대상(Resource)에 작업(Action)을 조건(Condition)에 따라 허용여부(Effect)를 결정하는 것
간단히 말하자면 행위자(사람)에게 부여하는 정책이다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bizhub.hy"
}
]
}
위 정책은 “bizhub.hy 라는 s3 버킷에 읽기 권한을 부여함” 이라는 정책이다. 그런데 누가? Principal 이 빠져있다. 왜냐하면 이 정책은 사용자에게 부여하기만 하면 그 사용자는 “bizhub.hy 라는 s3 버킷에 읽기 권한을 부여함” 이라는 권한을 흭득하기 때문이다.
여기서 말하는 사용자는 IAM user, group, SAML 인증된 사용자 등을 의미한다.
일일이 누가(Principal)을 정의하지 않아도 되기 때문에 모듈화 되어 재활요이 가능하다는 특징이 있다.
만약 100명의 유저에게 “bizhub.hy 라는 s3 버킷에 읽기 권한을 부여함” 정책을 주려면 100개의 정책을 만들어 일일이 누구에게를 지정해야 할 것이다.
사용자, 그룹 등 대상에게 정책을 추가하기만 하면 된다.
Resource 기반 정책
대상(Resource)이 누구(Principal)에 작업(Action)을 조건(Condition)에 따라 허용 여부(Effect)를 결정하는 것
대상에게 부여되는 정책입니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3GetObject",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:123456789:user/a-user-1"
},
"Action": "S3:GetObject",
"Resource": "arn:aws:s3:::bizhub.hy"
}
]
}
위 정책은 “bizhub.hy 라는 S3 버킷에 읽기 권한을 계정 123456789 의 a-user-1 에게 부여함” 이라는 정책이다.
identity 기반 정책과 다르게 Principal 이라는 “누구”가 정의되어야 한다.
identity 기반 정책인 정의된 정책들을 유저에게 부여했다면 리소스 기반 정책은 해당하는 대상에 직접 정의해야 한다.
S3 콘솔의 버킷 정책에서 정의할 수 있다.
사람에게 정책을 부여해야 할지 똔느 대상에게 정책을 부여해야 할지 또는 둘 다에게 부여해야 할지 고민될 것이다.
예를 들어 Account1 의 사용자 user-1 과 s3 버킷 myS3 가 있다고 가정하고 이들에게 읽기 권한을 주고자 한다.
Account1 의 user1 는 Account1 의 myS3 에 대해 읽기 권한을 허용함
or
Account1 의 myS3 에는 Account1 의 user1 에게 읽기 권한을 허용함
둘 중 하나의 정책만 부여되기만 하면 권한을 부여 받을 수 있다.
그런데 만약, Account2 계정의 user-2 가 Account1 계정의 S3 버킷 myS3 에 읽기 권한을 얻고자 한다면?
Account2 의 user-2 는 Account1 의 myS3 에 읽기 권한을 허용함
or
Account1 의 myS3 에는 Account2 의 user-2 에게 읽기 권한을 허용함
IAM 의 정책이 사용자(Identity) 와 자원(Resource) 에 부여됨과 차이점에 대해 알 수 있었다. 정책의 경우 한 번 부여되게 되면 영구적으로 권한을 가지게 된다는 특징을 가지고 있어 보안상 우려가 될 수 있다.
Condition 을 통해 특정 아이피, 특정 시간대에만 권한을 허용해 줄 수 있지만 기능이 한정적이다. 권한을 임시적으로 부여할 수 있는 역할(Role) 이 존재한다.
Role
정책은 역할과 IAM 사용자에게 부여할 수 있다. 정책은 한 사람, 한 그룹 단위로 할당해주지만 역할은 다수의 사람이 역할을 맡을 수 있다.
액세스 키 또는 암호를 알고 있다면 일부로 이를 바꾸지 않는 한 영원한 크레덴셜이다.
임시 보안 자격 증명은 유효한 시간이 지난 후에는 사용 불가능한 크레덴셜이다. IAM 사용자가 역할을 맡는다는 것은 임시 보안 자격 증명을 통해 임시적인 시간(에를 들어, 1시간) 동안만 역할을 맡고 그 이후에는 역할을 반납한다.
정책은 한 번 부여한 뒤 회수하지 않는 한 영구적으로 권한을 부여받는다.
IAM 사용자가 S3 버킷에 접근하고 싶을 때, 두 가지 방식으로 권한을 부여할 수 있다.
- 정책을 사용자에게 할당한다.
- 역할을 위임받는다.
아래와 같은 정책을 생성한다. bizhubcentrify 라는 s3 버킷에 대해 읽기 쓰기 권한을 얻는 정책을 만들고 이 정책을 IAM 사용자에게 할당한다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3ReadWrite",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::bizhubcentrify"
]
},
{
"Sid": "AllowList",
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "*"
}
]
}
Sid : 아주 간단하게 보자면 제목, 부제 정도로 생각하면 될 것 같다.
Effect : 해당 Resource 에 Action 을 허용할 것인지 거부할 것인지를 작성한다.
Resource : 내가 접근하고자 하는 AWS Resource 에 대한 arn 을 작성한다. 이 부분은 더 찾아볼 것
정책(Policy)이 아닌 역할(Role)을 통해 권한을 부여받는 방식
역할을 생성한 뒤 정책을 연결한다. 그리고 이 역할을 IAM 사용자에게 임시적으로 부여할 것이다.
IAM 사용자가 S3AccessS3 assume 역할을 위임받은 것을 볼 수 있다. 이 역할은 1시간 뒤에 반납되게 된다. 1시간 뒤에는 다시 아무런 권한을 가지지 못한 상태로 남게 된다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::598944169130:user/root"
},
"Action": "sts:AssumeRole"
}
]
}
Principal : AWS: arn…. → 해당 iam user 에게 모든 권한을 OPEN
Action : sts:AssumeRole → 임시 권한이라는 뜻
역할을 사용하게 되면 정책을 부여하는 방식과 권한을 따로 회수하지 않아도 되는 장점이 있다. 예를 들어 s3 버킷에 파일 하나를 업로드하려 할 때 s3 버킷 쓰기 역할을 위임받은 후 필요한 작업을 완료하면 된다. 1시간이 지난 후 자동으로 역할에서 해제된다.
정책은 부여, 회수를 통해 권한 관리가 가능하다. AWS 에서는 사용자에게 부여된 정책이 언제 사용되고 얼마 동안 사용되지 않은지를 보여주는 Access manager 를 통해 정책의 관리를 도와주고 있다.
그만큼 정책관리는 매우 중요한 업무이고 역할을 통해 권한 관리를 하게 되면 관리 측면에서 매우 편해진다.
정책과 역할을 잘 관리할 수 있느냐는 클라우드 보안에 있어 매우 중요한 부분을 차지하고 있다.