안녕하세요 이번 글에서는 평소 AWS 내의 리소스를 관리하며 , 대충 이해만 하고 넘어갔던 접근제어에 대해서 알아보겠습니다.
우선, 저 같은 경우는 그저 특정 리소스를 요청할 때마다, 필요한 권한을 포함한 해당 리소스의 모든 권한을 전부 허용해 주고 사용하곤 했었습니다.
또한, 해당 역할에 대한 이해와 동작 과정에 대한 이해 없이 무작정 권한을 할당해 주고, 사용하다 보니 자주 Permission denied라는 문구를 보곤 했었습니다.
따라서 AWS의 접근 제어 정책에 대한 정확한 이해가 필요해 해당 과정을 글로 녹여내게 되었습니다.
들어가며..
AWS 클라우드를 사용하는 몇 가지 방법이 있습니다.
웹 콘솔에서 조작하는 방법, AWS CLI로 사용하는 방법, AWS에서 제공하는 SDK를 이용해 여러 프로그래밍 언어로 API 호출하는 방법이 있죠.
첫 번째 방법을 제외한 CLI와 SDK를 사용할 경우, 매 API 호출마다 처리되는 인증 절차가 있습니다.
여기서 , IAM 사용자를 통해 발급받은 ACCESS KEY와 SECRET KEY( Secret Access Key)를 사용하게 되죠.
ACCESS KEY
- AWS 계정 또는 IAM 사용자를 식별하는 데 사용되는 고유한 식별자 입니다.
- 요청 주제 (Principal)을 인증합니다.
SECRET KEY
- HMAC ( Hash-based Message Authentication Code ) 서명값을 검증합니다.
- 요청의 특정 부분을 해싱하여 디지털 서명을 생성하고, 이 서명을 요청에 포함시켜 요청을 보내는 과정을 포함합니다.
- 이렇게 함으로써, 보내는 측이 요청을 생성한 적절한 사용자임을 인증합니다
AWS IAM ?
IAM은 AWS 전체의 권한 통제 시스템을 칭하는 말이며,
I ( Identity) : AWS로 요청을 할 수 있는 보안주체 (Principal)를 의미합니다.
AM ( Access Management) : 누가 어떤 리소스들에 대해 어떤 일을 할 수 있는 권한을 가지는지를 의미합니다.
IAM 보안주체 ( Principal) 는 여러 사용자 유형이 있는데, Cloud Trail 서비스에서 다음과 같이 구분이 됩니다.
- Root - API 요청이 AWS Account 자격 증명을 사용 ( 처음 계정 생성시 만들어지는 슈퍼 유저 )
- 모든 리소스에 대한 접근 권한이 있기 때문에 사용 안하는 것을 적극 권장 - IAM User - API 요청이 IAM User의 자격 증명을 사용 ( 장기 credential을 사용 )
- Assumed Role - API 요청이 AWS STS(Simple Token Service) AssumeRole을 통해 획득한 임시 보안 자격 증명을 사용
- AWS Account - 다른 AWS Account에서 요청
- AWS Service - AWS 서비스에 속한 AWS 계정을 통해 요청
위와 같은 형식으로 Cloud Trail 서비스 내에서 유저의 유형과, 유저의 이름, 해당 유저가 어떤 행동을 했는지 기록되게 됩니다.
해당 JSON을 이용하여, 보안 감사 및 추적의 목적으로 사용할 수 있겠죠 ?
IAM의 인증과 인가
AWS IAM은 권한 제어를 위한 인증과 인가를 둘 다 담당합니다.
우선 인증으로는 , 보안 주체 ( principal )가 갖게되는 credential은 장기 ( Long-term) 와, 임시 자격 증명이 있습니다.
대표적인 장기 credentials 로는 IAM User(사용자)의 자격 증명을 그대로 이용한 credential입니다.
( IAM User 생성시, 위에서 언급한 Access key와 Secret Key를 발급 받을 수 있습니다. )
반면에 임시 자격 증명으로는 IAM Role의 인증이 있습니다.
예를 들어, 특정 EC2 instance가 다른 AWS 리소스에 접근할 때 사용하는 역할등이 있겠죠.
( 이 과정에서도 특정 리소스를 호출 하는 과정이기에 인증과정이 이루어집니다. )
대신, IAM User의 자격증명을 그대로 이용하는 credential과는 달리, 해당 임시 자격 증명의 시간을 제한할 수 있습니다.
일련의 인증 과정을 거친후, 해당 인증된 사용자(또는 서비스)가 요청에 대한 정책이 허용이 된다면, 그제서야 API 호출은 성공하게 됩니다.
예시 )
- A라는 IAM User는 특정 리소스를 호출합니다. ( S3 Object Put, Get 등 )
- 해당 요청은 IAM 서비스를 통해 보안 주체(요청자)가 적절한 사용자인지 판단합니다(인증).
- 그 후, 인증된 사용자라면 해당 요청자의 권한을 확인합니다.
- 만약 정책에 맞는 요청을 했다면(인가) 요청을 받은 해당 리소스는 요청에 대한 응답을 합니다.
IAM Policy
위의 예시에서 "정책"을 언급했는데, 이 정책은 말 그대로 보안 주체가 가지고 있는 권한을 뜻합니다.
해당 정책의 구조는 대략 다음과 같습니다.
{
# 예시
"Version": "2012-10-17",
"Statement": [
{
# 허용 할건지, 거부 할 것 인지
"Effect": "Allow or Deny",
# 어떤 행동을 ?
"Action": [
"s3:Get",
"s3:Put"
],
# 어떤 리소스들에 대해 ?
"Resource": [
"arn:aws:s3:<BUCKET-NAME>:<OBJECT-PATH>"
]
}
]
}
이에 추가로, Condition 블록을 통해 조건을 걸어줄 수 도 있습니다. 위 코드 블럭에 추가하자면,
srcIP가 특정 대역에 속하는 경우에만 허용 같은것 말이죠.
어떤가요? 어느정도 이해가 되셨나요 ? 한 가지 더 재밌는 사실이 남았습니다.
바로 위에서 본 Policy JSON는 Identity Based(보안 주체 기반) Policy 이고, AWS 에서는 위와 유사하지만
Resource Based Policy( 리소스 기반 정책) 으로 종류가 나누어집니다.
위의 JSON 의 Statement 블록안에, Principal 블록이 추가 됩니다.
쉽게 설명하자면, 특정 리소스 ( 예 : S3) 에 특정 보안 주체 (principal)만 허용된 Actions를 수행 할 수 있다 입니다.
예를 들어보시죠 . IAM 사용자에게 역할을 연결하는 것과는 조금 다릅니다.
- S3 리소스를 생성합니다.
- 생성 후, 해당 S3에 접근할 수 있는 주체를 특정합니다. ( 예 : a라는 iam user의 ARN -> arn:aws:iam:<ACCOUNT_ID>:a_user)
- 해당 주체는 Put과 Get 호출을 할 수 있습니다.
- 그렇지만 특정 Path 에만 접근이 가능합니다. 또는 모든 Path에 접근이 가능합니다.
- 또한 , 특정 ip로만 접근할 경우에만 가능합니다. ( 예 : 회사 사무실의 공인 라우터 또는 게이트웨이 IP )
이를 JSON 형식으로 표현하면 다음과 같아집니다.
{
# 예시
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal" : {
"AWS" : [
"arn:aws:iam:<ACCOUNT_ID>:a_user"
]
}
# 어떤 행동을 ?
"Action": [
"s3:Get",
"s3:Put"
],
# 어떤 리소스들에 대해 ?
"Resource": [
"arn:aws:s3:<BUCKET-NAME>/<OBJECT-PATH>*"
],
"Condition" : {
"IpAddress": {
"aws:SourceIp" : "1.1.1.1"
}
}
}
]
}
그렇다면 여기서 궁금증이 생기실 수도 있을텐데요,
" 어라 ? 그럼 IAM 사용자가 리소스를 호출하려 할 때, 리소스 정책과, 유저 정책을 둘 다 만들어줘야 하나 ? , 둘 중에 하나만 열어줘도 되던데 ? "
저도 같은 생각을 했습니다만, 이는 반은 맞고 반은 틀렸습니다.
바로 같은 계정인지, 아니면 다른 계정인지에 따라 이는 구분이 되어 적용됩니다.
쉽게 설명하자면, 같은 Acount_id를 가지고 있는 IAM 사용자와 리소스일 경우에는 둘 중에 하나만 허용해줘도 API 호출이 가능합니다.
다만, 다른 Account_id를 가지고 있는 IAM 사용자와 리소스일 경우에는 , 둘 다 허용해줘야 API 호출이 가능해집니다.
즉, IAM 사용자는 해당 리소스에 대한 적절한 권한을 가지고 있어야 하고, 해당 리소스는 특정 IAM 사용자 ( 다른 계정의)의 ARN을 보안 주체 (Principal 블록) 에 작성해줘야 정상적인 호출이 가능해집니다.
또한, 사용자의 Effect는 특정 Actions가 Allow가 돼있고, 리소스에선 보안주체로 사용자가 명시 돼있어도 리소스 정책에서 Effect가 Deny가 돼있다면, AWS 정책상 Deny의 우선순위가 높기 때문에 사용자의 호출은 거부 됩니다.
마치며 ..
여기까지 IAM에 대한 기본적인 내용을 예시와 함께 간단하게 살펴보았습니다.
다음번엔 AWS 임시 자격증명의 유형과 사용방법에 대해 좀 더 알아보겠습니다.
긴 글 읽어주셔서 감사합니다.
'AWS' 카테고리의 다른 글
| AWS Cloud Support Associate 1차 면접 후기 (9) | 2023.12.12 |
|---|---|
| AWS ECS 오토 스케일링 및 배포 자동화 (0) | 2023.08.01 |
