Access Key
AWS Cli를 이용해서 접속할 때 Cli포스팅에서 제시한 AWS Cli를 OS에 맞게 설치하고 명령어를 입력합니다.
저는 Mac OS여서 AWS Cli를 설치한 다음 Terminal를 통해서 접속하였습니다.
[haams@haamsui-MacBookPro] ~ % aws configure
AWS Access Key ID [None]: -------------------
AWS Secret Access Key [None]: ----------------------------------
Default region name [None]: ap-northeast-2
Default output format [None]:
액세스 키가 생성되면 Terminal에서 위에 내용대로 진행하면 됩니다.
AccessKey, SecretKey는 생성된 대로 복사해서 넣으면 되고 region name은 현재 내 지역으로 셋팅하면 됩니다.
저는 서울이기에 거기에 맞는 ap-northeast-2 Region을 넣었습니다.
output format은 빈칸으로 두고 진행하시면 됩니다.
이렇게 하면 cli에서 AccessKey를 통해 AWS Console에 접근이 성공하게 됩니다.
여기서 접속한 계정은 액세스 키를 생성했을때 사용자이며, 현재 저는 액세스키를 생성할 당시 사용자가 admin 그룹에 속하여
Adminstrator Access 권한을 상속받은 사용자입니다.
따라서 계정 관련된 접근이 허용되므로 다음 명령어를 진행했을때 아래와 같이 결과가 나오게 됩니다.
haams@haamsui-MacBookPro ~ % aws iam list-users
{
"Users": [
{
"Path": "/",
"UserName": "haams",
"UserId": "**********************",
"Arn": "arn:aws:iam::**********:user/haams",
"CreateDate": "2023-01-02T05:32:58+00:00",
"PasswordLastUsed": "2023-01-03T00:59:29+00:00"
},
{
"Path": "/",
"UserName": "nk3722",
"UserId": "**********************",
"Arn": "arn:aws:iam::**********:user/nk3722",
"CreateDate": "2023-01-02T06:33:36+00:00"
}
]
}
마찬가지로 현재 사용자가 권한이 없다면 위 내용처럼 결과도 나오지 않을 것입니다.
IAM ROLE
- 신뢰하는 개체에 권한을 부여하는 것으로 일반적으로는 EC2, Lambda가 있다.
- AWS 서비스에서 사용할 AWS 서비스 요청을 위한 권한 집합을 정의하는 IAM Entity
예를 들어, AWS의 서비스 중에 EC2의 인스턴스가 있다. 이 인스턴스로 다른 AWS 서비스를 접근하고 싶은데 해당 권한이 없어서 접근할 수 없습니다.
EC2 인스턴스 자체적으로는 권한을 주고 받고 할 수가 없기 때문에 IAM Role(역할)을 셋팅해서 이 EC2 인스턴스와 함께 하나의 개체로 만들게 됩니다.
그리고 이 IAM Role에 Permission을 직접 부여하여 EC2 인스턴스가 다른 AWS 서비스를 접근할 수 있도록 만드는 것입니다.
다음처럼 역할에서 생성할 때 AWS 서비스를 선택하고 일반적인 사례로 쓰이는 EC2를 택하고 다음으로 넘어갑니다.
앞서 포스팅한대로 정책 생성해서 추가할 수도 있고 기존에 있던 여러 권한 정책에 대해서 선택할 수도 있습니다.
추가로 권한 경계를 설정할 수 있는데, 이는 일반적인 케이스가 아니여서 필수는 아니지만 설정하게 된다면 최대치의 권한을
땡겨 받을 수 있고 다른 사용자에게 권한을 위임하는 데에도 사용할 수 있습니다.
역할 이름을 정의하고 어떤 엔터티가 설정되었는지 확인할 수 있으며, 권한은 무엇이 부여되었는지 체크할 수 있다.
물론, 편집을 통해 권한을 추가로 정의할 수 있다.
역할을 생성하면 AWS 서비스(EC2 Instance)가 해당 역할을 가지며 그 역할에 부여된 퍼미션을 통해
타 AWS 서비스 또는 관련 권한을 통해 접근할 수 있는 서비스를 이용할 수 있습니다.
IAM 요약
※ 루트 계정은 AWS 계정 설정할 때를 제외하고는 가능하면 사용하지 않는다.
1) 하나의 사용자는 AWS 유저라 생각하면 되고, 다른 사람이 쓴다고 할 경우 자격증명을 넘기는 것이 아니라 새로운 사용자를 만들어 권한을 부여하거나, 그룹에 추가하여 이용할 수 있도록 한다.
2) 사용자는 그룹에 속하게 하여 그룹 차원에서 권한을 상속받아 이용하는 것이 모범적이다.
3) 비밀번호는 심화해서 설정하는 것이 좋고 MFA는 Root 계정과 사용자 각각 설정해서 보안을 더욱 강화하는 것이 좋다.
4) AWS 서비스(A)가 다른 AWS 서비스(B)를 이용하려고 할 때에는 관련 권한을 부여해야 하는데, 직접적으로 AWS 서비스(A)에 권한 부여가 되지 않기 때문에 IAM Role을 통해 권한을 부여하고 AWS 서비스(A)를 Role에 엮어 관리합니다.
그로 인해, 권한이 생긴 AWS 서비스(A)는 다른 AWS 서비스(B)를 접근할 수 있게 됩니다.
> AWS 서비스에서 사용할 AWS 서비스 요청을 위한 권한 집합을 정의하는 IAM Entity = IAM Role
5) CLI/SDK 접근할 때에는 Access Key로 접근하는 것이 좋습니다. 루트 계정이 아닌 사용자 계정으로 접근 키를 생성해서 접근하는 것이 좋으며, 접근 키는 반드시 본인만 알아야 합니다.
6) 계정 권한 감사는 IAM 자격증명 보고서, IAM 액세스 분석기, IAM Access Advisor를 통해 체크가 가능합니다.
IAM 액세스 분석기는 리소스에 대한 액세스 모니터링이며 IAM Access Advisor는 특정 사용자에 대해 권한 감사를 할 때 사용합니다.
AWS Shared Responsibility Model (공동책임모델)
1) AWS 책임("클라우드의 보안")
: AWS 인프라 측면에서 보안을 강화해야 합니다. AWS는 클라우드에서 제공되는 모든 서비스를 관리하는 인프라를 보호해야 합니다.
AWS 클라우드 서비스를 실행하는 하드웨어, 소프트웨어, 네트워킹 및 시설 등으로 인프라는 구성되어 있습니다.
2) 고객책임 ("클라우드에서의 보안")
: 고객이 선택하는 AWS 클라우드 서비스에 따라서 달라집니다.
보안 책임이 고객에게 있기 때문에 수행하는 구성 작업량 또한 선택한 서비스에 따라 달라집니다.
예를 들어, EC2 같은 경우는 IaaS이기 때문에 고객이 필요한 모든 보안 구성 및 관리 작업을 수행하도록 합니다.
인스턴스를 배포할 때에는 게스트 운영 체제의 관리(업데이트, 보안패치 등), 인스턴스에 설치된 모든 애플리케이션 소프트웨어 또는 유틸리티 관리, 그 외 AWS에서 제공한 방화벽 구성 관리 등이 있습니다.
S3나 DynamoDB와 같은 추상화 서비스의 경우, AWS는 인프라 계층, 운영 체제, 플랫폼을 운영하고 고객은 데이터를 저장하고 검색하기 위해 엔드포인트에 엑세스합니다.
고객은 데이터 관리(암호화 옵션 포함), 자산 분류, 적절한 퍼미션 부여에 따른 IAM 도구 사용에 대해 책임이 있습니다.
'Cloud' 카테고리의 다른 글
| AWS - Security group (2) | 2023.01.17 |
|---|---|
| AWS - EC2 (0) | 2023.01.17 |
| AWS - CLI & 사용자 정보 보호 (0) | 2023.01.17 |
| About IAM (0) | 2023.01.17 |
| AWS 소개 (0) | 2023.01.17 |
