[AWS] 📚 장기 자격 증명(Access Key) & 임시 자격 증명(AssumeRole) 사용법

AWS 자격 증명

AWS 액세스 방식에 따라 다양한 유형의 보안 자격 증명을 필요로 한다.

AWS에 로그인 하여 서비스를 이용하는 방법은 크게 두가지로 나뉜다.

 

콘솔 액세스 자격 증명

AWS 콘솔 웹 매니저에 로그인을 하기 위해 필요한 자격 증명이다.

우리가 이때까지 AWS 웹사이트에서 아이디/비밀번호를 쳐서 로그인 하듯이 사용하는걸 말한다.

크게 3가지로 나뉘는데, 다음과 같다.

• Root 이메일 / 비밀번호 : 루트 로그인을 위해 사용
• IAM 유저명 / 비밀번호 : IAM 유저가 로그인 하기 위해 사용
• MFA(Multi-Factor authentication) : 다른 자격 증명에 보안을 강화하기 위한 임시 비밀번호 

---

프로그램 방식 액세스 자격 증명

AWS 웹사이트에서 로그인해 사용하는 콘솔 엑세스 자격 증명과는 달리,

프로그램 방식 엑세스 자격 증명은, AWS의 CLI 혹은 AWS SDK를 사용할때 필요한 자격 증명이다.

프로그램 방식 엑세스 자격 증명은 다시 크게 장기 자격 증명(Long-Term Credential)과 임시 자격 증명(Temporary Credential)로 구성된다.

AWS CLI란?
쉽게 말해 리눅스처럼 터미널에서 aws 서비스를 다룰수 있게하는 서비스이다.
예를 들어 리눅스에서 파일 복사, 폴더 생성, 이동, 삭제 등에 이용되는 ls, rm, cp 와 같은 명령을 AWS S3에 고대로 사용할수 있다.

AWS SDK란?
쉽게 말해 aws 서비스를 쉽게 이용할 수 있게 해주는 미리 만들어 놓은 코드 패키지라 보면 된다.
예를 들면 안드로이드 스튜디오도 안드로이드 어플을 개발하는 SDK라고 말할 수 있다.
즉, AWS SDK는 AWS 서비스를 유기적으로 연동해서 개발할수 있게 하는 툴(SDK).

AWS CLI

AWS SDK

---

프로그램 방식 엑세스 자격 증명 구성

프로그램 방식 엑세스 자격 증명 구성에는 다음 3가지가 존재한다.

• Access Key ID : 유저 이름에 해당하는 키. 일반적으로 공개되어도 무방
• Secret Access Key : 패스워드에 해당하는키. 공개되면 안됨
• Token : 임시 자격 증명에만 사용. 임시 자격 증명이 유효한지 검증하기 위해 사용

 

실무를 예시를 든다면, 개인 서버에서 AWS 서비스에 접속해 서비스를 이용하기 위해서는 당연히 로그인(자격 증명)이 필요한데, 이때 아이디와 비밀번호를 보내주는게 바로 Access Key 이다.

그러면 AWS에서는 받은 Access Key를 파싱애 유저가 누구인지 역할(Role)은 무엇인지 파악해 S3 서비스에 엑세스하여 사용할수 있는 것이다.

---

장기 자격 증명

장기 자격 증명은 IAM 유저로 부터 생성되는 것이다.

우리가 root 계정으로 IAM 유저를 생성할때, 막바지 부분에서 csv파일을 다운 받을수 있는데, 이 안에 Acess Key ID와 Secret Access Key 부분이 바로 장기 자격 증명 이다.

이 말은, AWS 웹 콘솔에 Use name과 Password를 입력해 로그인해 AWS 서비스를 이용하듯이, Access Key ID와 Secret Access Key를 통해 AWS CLI에 로그인해서 AWS 서비스를 이용하는 원리이다.

즉, IAM 계정이 있다면, 이 IAM 계정에 접속하는 방법은 아이디/패스워드 와 AccessKey/SecretKey 두가지가 있다고 보면 되며, 아이디/패스워드는 AWS 웹 콘솔에 AccessKey/SecretKey는 AWS CLI나 SDK에 접속하여 사용 하는 것으로 이해하면 된다.

 

장기 자격 증명은 반 영구적이라, 삭제 하지 않으면 유효기간 없이 계속 사용이 가능하다는 특징을 가지고 있다.

이 말은, 만일 장기 자격 증명을 누군가에게 탈취 당할경우 어떻게 조치할 방도없이 그대로 해킹된다는 소리이다. (게임 아이디 같은경우 해킹당해도 피해가 있을 지라도 비밀번호를 바꿀수 있지만, 장기 자격 증명은 반 영구적이기 때문에 비밀번호 변경이 불가능하다)

그래서 주로 어플리케이션에 하드코딩되어 사용된다.

실제 사례로, 깃헙에다가 실수로 Access Key를 유출되서 누가 그대로 탈취해 AWS 계정에 접속해 비트코인을 채굴하여 시간당 몇백만원이 과금되는 피해 사례도 존재한다.

 

IAM 유저 하나당 2개의 자격 증명 발급 가능하다.

Access Key ID는 다시 볼수있지만, Secret Acces Key 같은 경우 만일 유실되면 절대 복구가 불가능하니 다시 재발급 하는 방법 밖에 없다.

또한 장기 자격 증명은 활성화/비활성화 기능을 지원한다.

만일 AWS를 쓰지 않을경우 Access key를 비활성화 해둘수 있다. 다만, 비활성화 하더라도 2개 초과의 자격 증명 발급은 역시 불가능하다.

따라서 이러한 특징 때문에 장기 자격 증명을 통해 AWS에 엑세스 하는건 비추천 되어지는 편이며, 임시 자격 증명을 통해 기간으로 엑세스 하는 방식으로 관리되는 것을 권장되어지는 편이다.

---

임시 자격 증명

임시 자격 증명은 단기로 사용할 수 있는 자격 증명이다.

몇분에서 몇시간 까지 지속시간이 정해져 있어서 '임시' 라는 말이 들어간다. 자격 증명이 만료된 이후에는 어떤 종류의 액세스도 허용되지 않는다.

필요한 시점에서 바로바로 생성해서 활용하고 이후 필요에 따라 재 발급도 가능하다.

임시 자격 증명은 동적으로 생성되어 요청한 사용자에게 제공된다. 단, 해당 사용자는 자격 증명을 요청할 수 있는 권한이 있어야 한다.

 

그래서 임시 자격 증명은 보안이 매우 뛰어나다.

애플리케이션으로 장기 AWS 보안 자격 증명을 배포 또는 포함할 필요가 없으며, 사용자에 대한 AWS 자격 증명을 정의하지 않고도 AWS 리소스에 대한 액세스 권한을 사용자에게 제공할 수 있다.

또한 임시 자격 증명은 관리가 쉽다. 동적으로 생성되고 자동으로 로테이션 되기 때문에 권한의 부여 및 회수가 쉽기 때문이다.

따라서 최대한 장기 자격 증명 보다는 임시 자격 증명을 최대한 활용하는게 좋은 방법이다.

 

자격 증명 연동

임시 자격 증명은 IAM 유저 외에 다양한 Identity에게 자격 증명 부여 가능하다.

AWS 밖의 외부 시스템에서 사용자 자격 증명을 관리할 수 있고 그 시스템으로부터 로그인하는 사용자에게 액세스 권한을 부여하여 AWS 작업을 수행하고 AWS 리소스에 액세스하도록 할 수 있다.

예를 들어 페이스북이나 구글 같은 외부에서 로그인한 유저에게도 자격을 부여해 내 AWS 서비스를 이용하도록 하거나 심지어 사람이 아닌 EC2에게도 권한을 부여할 수 있다.

이 부분은 동시에 IAM 역할(Role)의 특징이기도 하며, 임시 자격 증명은 역할(Role)을 이용해서 자격을 부여하는 것으로 이해하면 된다.

IAM 에서는 두 가지 유형의 자격 증명 연동을 지원하며, 자격 증명은 모두 AWS 외부에 저장된다.

• 엔터프라이즈 자격 증명 연동
  임시 액세스 권한에 대한 SSO(Single Sign-On) 연동을 통해 조직의 네트워크에서 사용자 인증을 통한 AWS 액세스 권한을 사용자에게 제공할 수 있다.
  AWS STS 에서는 SAML 2.0 기반 연동 을 지원한다.
• 웹 자격 증명 연동
  Login with Amazon, Facebook, Google 또는 OpenID Connect(OIDC) 2.0 호환 공급자와 같은 유명한 타사 자격 증명 공급자를 사용해 사용자가 로그인할 수 있다.

 

임시 자격 증명 생성

임시 자격 증명은 AWS STS(Security Token Service) 서비스를 사용해서 생성할 수 있다.

그리고 IAM 유저나 Web Identity(Facebook 유저)가 특정 역할(Role)을 Assume(뜻: 제것으로 삼다)하여 자격 증명 생성해서 역할에 부여된 모든 권한을 행사 가능하다

 

유저가 role을 assume하다라는게 무슨말이냐면,

아래 사진과 같이 일개 IAM 유저가 어드민 Role 모자를 쓰면(assume) 마치 유저가 어드민 처럼 되서 어드민 권한을 행새 하는 것을 뜻한다.

이러한 모자를 쓰는 행위를 assumeRole 이라고 한다.

사진의 우측부분에 Access Key들이 있는데 이것이 임시 자격 증명이며, IAM 유저가 어드민 Role 모자를 쓰게되면서 임시 자격 증명이 발급된다 라고 이해하면 된다.

 

AWS의 IAM 계정 뿐만 아니라, 페이스북 같이 유명한 타사 자격 증명 공급자를 assume하여 역시 어드민 행새를 할수 있다.

그리고 이를 assumeRoleWithWebIdentity 이라고 한다.

 

임시 자격 증명 제한

임시 자격 증명에 제한을 걸기 위해서는 Permission Policy 설정이 가능하다.

위 사진 보듯이 Effective Permissions라고 마치 교집합 형태로 되어있는데, 이는 노랑 Policy에서 가능한 권한들하고 파랑 Policy에서 가능한 권한들을 교집합해 겹치는 부분 권한만 사용할 수 있다는 원리로 이를 통해 자격 제한을 두는게 가능하다는 것이다. 

좀더 자세히 설명하자면, IAM 유저에게 S3의 모든 권한(*)을 가진 역할(모자)를 씌워줄텐데, 여기서 Permission Policy라는 것을 같이 부여하면은 이 두개가 교집합 되어, 결국 겹치는 부분만 IAM 유저가 권한을 얻어 S3를 getObject(객체 조회) 하는 액션만 행동할수 있다는 원리이다.

---

임시 자격 증명 부여하기 [실전 구축]

앞서 배웠던 것처럼, 아무 권한 없는 IAM 유저를 하나 생성하고, S3엑세스하는 모든 권한을 가진 Role을 씌워, 임시적으로 S3를 마음대로 다룰수있는 IAM 유저로 변모시키는 과정을 실전으로 세팅 해보는 시간을 가져보자.

---

1. IAM User 생성하기

---

2. AssumeRole 인라인 정책 부여하기

인라인 정책은 자격 증명에 내장된 형태로 존재하는 것으로, 자격 증명의 파라미터 중 하나로서 생각하는 것으로 이해하면 된다.

assumrole은 아무나 막 할 수 있는게 아니다.

assumrole이라는 정책은 IAM 유저에게 부여해줘야, IAM 유저는 역할을 부여받을수있게 된다.

---

3. IAM 역할(Role) 생성

---

4. S3 버킷 만들기

---

5. EC2 인스턴스 생성 및 CLI 연결

테스트를 위한 인스턴스 하나를 만들어준다. 옵션은 amazon-linux-ami에 모두 디폴트로 둔다.

EC2가 준비되었으면 연결 버튼을 눌러 인스턴스 CLI 창으로 들어간다.

---

6. AWS CLI에서 장기 자격 증명 입력하기

아까 beggar 라는 IAM 유저를 생성했을때 미리 다운 받았던 csv 파일을 연다.

이 csv 파일에 적혀있는 Access key ID(아이디)와 Secret access key(비밀번호)를 AWS CLI 터미널에 입력한다.

$ aws configure # 인증 정보 설정
AWS Access Key ID [None]: AKIAYXPEPKI7CO4LIV67
AWS Secret Access Key [None]: ***********************
Default region name [None]: ap-northeast-2
Default output format [None]: json


$ aws configure list # 설정한 인증 정보를 확인
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************IV67 shared-credentials-file    
secret_key     ****************pVnu shared-credentials-file    
    region           ap-northeast-2      config-file    ~/.aws/config

설정을 완료하게 되면, 현재 터미널에 있는 나의 자격은, 방금 넣은 access key에 대표되는 IAM 유저가 되는 것이다.

aws configure 정보를 등록하게 된다면, 
.aws 라는 폴더에 config와 credentials 파일이 생성되게 된다. ( $ ll .aws 명령어 실행)
여기에 인증정보가 저장되니, 인스턴스를 재부팅해도 인증정보가 계속 인스턴스에 유지되게 된다.

만일 터미널에 입력한 access key에 대표되는 IAM유저가 만일 루트 어드민 권한을 가지고 있다면, 자격을 configure하면 이제 마치 어드민처럼 AWS 서비스 이리저리 엑세스하거나 수정할수 있게 된다.

그런데 위에서 IAM을 생성했을때 유저에게 assumerole 이외에 아무런 권한을 주지 않았다.

따라서 S3 명령어를 실행해도 AccessDenied 라는 경고 문구가 표시되게 된다.

$ aws s3 ls # S3에 있는 버킷들을 나열하는 명령어

---

7. AWS CLI에서 AssumeRole 하기

이제 아까 생성했었던 S3엑세스권한을 가지고 있는 IAM Role(s3-assume-role)을 현재 터미널 자격(IAM beggar 유저)에게 부여해볼 것이다.

$ aws sts assume-role 명령어에 --role-arn 옵션으로 위에서 생성한 IAM Role의 ARN값을 넣고 --role-session-name 을 통해 세션이름을 아무거나 정해준다.

$ aws sts assume-role \ 
> --role-arn arn:aws:iam::600163963454:role/s3-assume-role \
> --role-session-name MySessionName

 

그러면 아래와 같이 json값을 반환하는데, 이것이 바로 임시 자격 증명서 이다.

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAYXPEPKI7AELVXXQGV:MySessionName", 
        "Arn": "arn:aws:sts::600163963454:assumed-role/s3-assume-role/MySessionName"
    }, 
    "Credentials": { // 임시 자격 증명서
        "SecretAccessKey": "zbNCsHHT1MhUpuxEy1tGzI75UERZko0cHWSOE+lB", 
        "SessionToken": "IQoJb3JpZ2luX2VjELT//////////wEaDmFwLW5vcnRoZWFzdC0yIkgwRgIhAIB2NRQ1xUtPGbOkA46XWf7n+gEOVb23hk2i9QleIcsBAiEApBihsYumSlviN0hFZwJ901MMlQhOwiJZuMxRrCMCMzcqmgIIXRAAGgw2MDAxNjM5NjM0
NTQiDC7cpzBNqWEFbrf36Sr3AQaqaEIxgaiGUcBCtpnz3mL0lX2hjteJ3guZckdyeWw8DTuu2OuRaFcbJgbJa41JUYQYytONj1VQvRTh8O/d1LeQYtwGO46ccKYAqBezMHml+hu7KX82ioaGl1QzWPMqzNVblnPJw3xxsSynyOO3qj+x5HSvhxYSO3HpfR//IJWqk5VTs
AjC0FFBpNj40a/hLiJ6+3QvLSfYGc1vMdzXJc7PUdf9F5Y5wooJWSrNsIjRbLWmeIknPAxvmUh6yurVNIurr/7T6KXr9fl3tbBrPO5aU+mr2pzJNyZt6XRh2HugxlvX2Q3mflfWAyePzGlF/5cGyTwOK2ww2O/akgY6nAE508MVZO81dKWKVLSUZwk0k5xy+PL7mKafgd
9iLDXGnGlusIyTmOVgjsJK/nChQ9tP0hrVFAj6LNbxod0KGIWrqzN6RhQZo4nrKAbIuI4clWqXtCbqmENNCZzOcvx5M06EKNnCN3nkn9A2Cyhba36Qg7jBZwGN6SqDaxkajO9LFV9EaamiBSO1ckxqyC5DNZgBmX3jfXgebxYzVmk=", 
        "Expiration": "2022-04-13T12:45:28Z", // 토큰 만료 시간
        "AccessKeyId": "ASIAYXPEPKI7MQO6G6MO"
    }
}

 

이제 발급받은 키 문자열을 현재 터미널 자격에 재등록을 해준다.

AWS_ACCESS_KEY_ID 환경변수에 위에서 발급 받은 임시 증명서의 키들을 넣어 터미널의 자격 증명 환경 설정을 하는 것이다.

$ aws configure set aws_access_key_id <AccessKeyId 문자열>
$ aws configure set aws_secret_access_key <SecretAccessKey 문자열>
$ aws configure set aws_session_token <SessionToken 문자열>

 

그리고 s3를 조회해보면 버킷명과 파일들이 나오는걸 확인 할 수 있다.

발급 받은 IAM Role의 임시 자격 증명서에는 S3를엑세스 하는 권한이 들어있었기 때문에 가능한것이다.

$ aws s3 ls # 버킷 나열

$ aws s3 ls <버킷명> # 해당 버킷에 있는 파일들 나열

---

임시 자격 증명서 발급 과정 정리

지금까지의 증명서 발급 순서를 정리하자면 다음과 같이 된다.

1. AWS CLI에 access key와 secret access key를 넣어 IAM 유저 자격(장기 자격 증명서)을 터미널에서 획득
2. $ aws sts assume-role 명령어를 통해 IAM Role을 불러와 임시 자격 증명서를 획득 (단연히 IAM 유저에게는 assumrole을 행할수있는 권한이 주어져 있어야 한다)
3. 발급받은 임시자격 증명서의 키와 토큰들을 CLI에서 다시 configure 한다.
4. 그러면 일정 기간동안 IAM Role에 있는 권한을 구행할 수 있게 된다.

---

# 참고자료

https://www.youtube.com/watch?v=pLlX-uxhsXg&t=1040s