AWS, IAM
안녕하세요❗️ 오늘은 IAM에 대해서 알아보겠습니다.
AWS에 대해 많이, 그리고 자세히 안다고 하지는 못하지만 AWS 서비스들을 사용하면서 빠짐없이 나온 개념이 바로 오늘 다루게될 "IAM"이기 때문입니다.
그럼, 오늘 목차를 확인하고 자세히 알아보도록 하겠습니다.
***************** INDEX *****************
🔑 IAM❓
💼 How IAM works
⚖️ Policies
********************************************
⚖️ IAM ❓
IAM은 Identity and Access Management의 약자입니다.
AWS 리소스와 서비스에 대한 인가를 설정할 수 있습니다.
인증은 "이 사람이라고 주장하는 그 사람이 맞다."
인가는 "인증된 이 사람이 어떤 권한을 갖고 있는지 확인"
예를 들어 P라는 사람이 A라는 접근을 할 수 있는지 없는지를 설정하는 것입니다.
AWS에서는 Policy를 정의할 때, 어떤 IAM Principle 이 어떤 Condition에서 AWS의 어떤 Resource 에 대해 어느 Action을 허용할지, 혹은 차단할 지를 지정합니다.
위의 문장이 어려우신가요?
아래의 내용을 읽고 나면 문장을 읽고 바로 그 내용을 이해하실 수 있을거에요❗️
왜 사용할까❓
AWS에서 IAM를 사용할 수 밖에 없는 특징들이 있는데요.
같이 살펴보도록 하겠습니다.
✔️ AWS 계정 공유 액세스 Shared access to your AWS account
여러 사람이 비밀번호나 Access key를 공유하지 않고도 리소스를 관리하고 사용할 수 있게 권한을 줄 수 있습니다.
✔️ 세분화된 권한 Granular permissions
사용자에게 자원에 따라 서로 다른 권한들을 부여할 수 있습니다.
누군가에게 S3를 읽어올 수만 있게 하지만, EC2 인스턴스에 대한 모든 권한을 줄 수도 있는 것이죠.
✔️ 실행중인 EC2로부터 AWS 리소스에 대한 접근 제어
Secure access to AWS resources for applications that run on Amazon EC2.
안전하게 EC2 인스턴스에서 실행되는 프로그램에 대해 자격을 증명해줄 수 있습니다. 덕분에 실행되고 있는 응용 프로그램이 다른 AWS 리소스에 액세스할 수 있는 권한을 제공해주죠.예를 들어 실행되고 있는 EC2 응용프로그램이 S3 버킷과 DynamoDB 테이블에 접근 여부를 설정할 수 있습니다.
✔️ Multi-factor authentication (MFA)
다중 인증을 제공해줍니다. 한 개 이상의 방법 혹은 절차를 통해 특정한 행동을 할 수 있는 권한을 부여한다는 의미입니다.
예를 들어 핸드폰에서 계좌이체를 하려고 할 때, (1) 핸드폰 잠금을 해제하고, 해당하는 (2) 은행 어플에 대한 인증을 한 번 더 하고, 계좌와 금액을 입력하고 (3) 한 번 더 인증을 해야 이체를 할 수 있습니다.왜 이렇게 많은 인증들을 필요로 할까요?
바로 다중인증을 통해 보안이 더욱 좋아지기 때문입니다.
IAM은 바로 이 MFA를 지원하고 있습니다.
✔️ 자격 증명 연동 Identity federation
소셜로그인 사용해보셨나요?
애플리케이션을 사용할 때, 번거로운 로그인 절차를 거치지 않고 연결된 소셜에 로그인(인증)이 되어 있으면 해당 애플리케이션에서 따로 인증을 하지 않아도 되기 때문에 편리하게 사용할 수 있습니다.
IAM도 회사 네트워크나 인터넷 ID 공급자와 같이 다른 곳에 이미 암호를 가지고 있는 사용자가 접근할 때,
AWS 계정에 임시로 액세스하도록 허용할 수 있습니다.
💼 How IAM works
IAM의 작동 방식에 대해 알아보면서 IAM에 대한 더 깊은 이해를 가져보도록 하겠습니다 〰️
AWS에서 제공해주는 이미지를 가져와보았습니다.
위의 그림이 객체가 서비스를 요청하고 사용하는데 거치는 인증과 인가에 대해 표현을 잘 해두었다고 생각이 들어요!
같이 한 번 살펴볼까요.
📌 Principal
Principal은 AWS 리소스에 대한 action이나 operation을 요청할 수 있는 사용자 또는 응용 프로그램입니다.
Principal은 요청을 하기 위한 루트 사용자나 IAM Entity로 인증됩니다.
매일 이루어지는 작업에 루트 사용자를 사용하는 건 최대한 지양하고,
IAM 엔티티(사용자 및 역할)를 활용하는 것이 좋습니다.
연합(federated) 사용자나 코드를 사용해서 응용 프로그램이 AWS 계정에 액세스할 수있게끔 만들 수도 있습니다.
📌 Authorization
Principal에 대한 인증(Authentication)이 되면 요청을 완료할 수 있는 권한이 있는지 확인합니다.
AWS는 request context를 확인하여 해당 요청을 허가할지 거부할지에 대한 정책들을 점검하게 됩니다.
정책은 JSON의 형태로 저장되어 principal entities(접근하는 주체)에 대한 권한을 지정합니다.
다양한 권한을 부여할 수가 있는데,
기본적으로 모든 권한은 거부 상태입니다. (루트 사용자 제외, 암묵적 거부라고 합니다.)
명시적으로 허용하는 경우 권한을 허가합니다.
권한 할당은 아래와 같이 적용이 됩니다.
오랜만에,, 일러를 꺼내들었습니다,,,
명시적인 허용을 해도, 명시적 Deny가 있다면 요청이 거부됩니다.
정책을 허용해도 범위에 대한 허용(권한 경계)을 명시하지 않으면, 접근할 수 없게 됩니다.
요청에 대한 정책과 권한은 아래 Policy 설명 부분에서 더 자세히 살펴보겠습니다.
📌 Actions and Operation
요청이 인증 과정과 인가 과정을 거치고 나면, 요청 작업을 진행합니다.
작업은 바로 서비스로 정의되며 리소스를 보거나 생성, 편집 및 삭제와 같이 리소스에 대해 수행할 수 있는 사항들이 있습니다.
예를 들어서 사용자 리소스를 접근할 때 CreateUser, DeleteUser, GetUser, UpdateUser 와 같은 액션을 수행할 수 있죠.
이 밖에도 약 40개의 작업을 수행할 수 있다고 합니다.
📌 Resources
AWS가 요청의 작업을 승인하면 관련 리소스에서 해당하는 작업을 수행할 수 있습니다.
리소스는 서비스 내에 존재하는 객체인데, Amazon EC2 인스턴스, IAM 사용자 및 Amazon S3 버킷 등이 있습니다.
⚖️ Policy
AWS에서는 Policy를 정의할 때, 어떤 IAM Principle 이 어떤 Condition에서 AWS의 어떤 Resource 에 대해 어느 Action을 허용할지, 혹은 차단할 지를 지정합니다.
위에서 읽었던 문장이 이제는 조금 이해가 가시나요❓
이제는 정책에 대해 조금 더 깊숙이 알아보려고 합니다.
정책 유형은 주체나 범위 등 기준에 따라 많은 모습으로 보입니다.
대표적으로 Identity-based policies 가 있는데요,
관리형 정책이나 인라인 정책을 IAM 개체(사용자, 사용자가 속한 그룹, 또는 역할)에 연결하여 개체 중심으로 권한을 부여하는 방식입니다
추가로, Resource-based policies 도 있습니다.
리소스에 연결하는 JSON 정책입니다.
예를들어 S3의 버킷의 정책이 있습니다.
IAM Policy의 구조는 JSON이며, 큰 틀은 아래와 같습니다.
{
"Version": "2012-10-17",
"Statement": [
...
]
}
위의 형식을 기반으로 권한을 추가시킬 수 있습니다.
어떤 속성이 있는지 확인해보도록 하겠습니다.
✔️ Version
정책 언어의 버전을 지정합니다.
가장 좋은 방법은 최신 '2012-10-17' 버전을 사용하는 것입니다.
✔️ Statement
이 주요 정책 요소를 다음 요소의 컨테이너로 사용합니다.
정책에 설명문 둘 이상을 포함할 수 있습니다.
✔️ Sid
(option) 사용자의 statement와 다른 추가적인 statement ID를 적습니다.
✔️ Effect
'Allow' 또는 'Deny'를 사용하여, 액세스를 허용할건지 거부할 것인지를 명시적으로 나타냅니다.
✔️ Principal
(option) 리소스 기반 정책을 생성하는 경우 액세스를 허용하거나 거부할 계정, 사용자, 역할 또는 연동 사용자를 표시합니다.
✔️ Action
정책이 허용하거나 거부하는 작업 목록을 포함합니다.
✔️ Resource
(option) IAM 권한 정책을 생성하는 경우 작업이 적용되는 리소스 목록을 지정합니다.
작업이 적용된 리소스에 경우엔 사용하지 않습니다 〰️
✔️ Condition
(option) 정책에서 권한을 부여하는 상황을 지정합니다.
실제 정책 JSON을 같이 보도록 하겠습니다
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FirstStatement",
"Effect": "Allow",
"Action": ["iam:ChangePassword"],
"Resource": "*"
},
{
"Sid": "SecondStatement",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "ThirdStatement",
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*"
],
"Resource": [
"arn:aws:s3:::confidential-data",
"arn:aws:s3:::confidential-data/*"
],
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}
]
}
FirstStatement라는 Sid가 설정된 첫 번째 statement는 사용자(iam:)가 자체 암호를 변경(ChangePassword)하도록 허용합니다.
이 문에서 Resource 요소는 “*”(모든 리소스)이지만 요청을 수행한 사용자의 암호에만 영향을 미칩니다.
두 번째 문(SecondStatement)은 사용자가 자신의 AWS 계정에 있는 모든 Amazon S3 버킷을 나열할 수 있도록 합니다.
이 문에서 Resource 요소는 "*"("모든 리소스를 의미)이지만 정책에서 다른 계정의 리소스에 대한 액세스 권한을 부여하지 않으므로 사용자는 자신의 AWS 계정에 있는 버킷만 나열할 수 있습니다.
세 번째 설명문은 사용자가 confidential-data라는 버킷에 있는 객체를 나열 및 검색할 수 있도록 하지만,
Condition의 영향으로 사용자가 멀티 팩터 인증(MFA)에서 인증한 경우에 한합니다.
정책 문에 Condition 요소가 포함된 경우, Condition내의 요소가 true인 경우에만 해당 문이 유효합니다.
이때 Condition은 사용자가 MFA 인증된 경우에 true로 평가되어 권한을 얻지만, 사용자가 MFA 인증되지 않은 경우엔 Condition이 false로 평가되어 권한을 얻지 못하고 액세스할 수 없습니다.
지금까지 IAM에 대해 알아보았습니다❗️
배울게 무지하게 많다는 걸 요즘 많이 느끼네요,,,🔥