AWS 를 사용할 때 웹에서 접속하는 방법도 있지만, 로컬 PC에서도 접속 가능하다.
AWS 를 로컬 PC 에서 접속하는 이유는 AWS CLI 를 사용하거나, Terraform 및 Ansible 등의 IaC 를 사용하기 위함이다.
그러나 로컬 PC 에서의 접속은 크리덴셜을 로컬 PC 에 저장하기 때문에, 악성코드 및 악성스크립트에 의해 외부로 유출 될 수 있다.

그래서 별도의 보안 조치를 통해 로컬에서 안전하게 AWS 로 접속할 수 있는 방법을 고민해야 한다.

로컬에서 AWS 에 안전하게 접속할 수 있는 방법은 여러가지며, 아래와 같다.

- aws vault
- HashiCorp Vault
- AWS Security Token Service
- AWS IAM Identity Center (SSO)
- Identity Federation (IDP) 사용

1. AWS VAULT

  로컬 PC 에서 AWS 에 접속할 때 크리덴셜을 안전한 저장공간에 암호화하여 저장하는 방법이다. 안전한 저장공간으로는 Keychain (MAC OS), Credential Manager (윈도우 자격증명 관리자) 를 들 수 있다. (이를 백엔드 라고도 한다.)

AWS VAULT 는 자격 증명 저장 > 임시 세션 요청 > STS 토큰 발급 > 할당된 작업 수행
으로 이루어진다.

- 크리덴셜을 암호화해서 안전한공간에 저장하므로, 로컬에 크리덴셜을 평문저장하여 접속하는 방식보다 안전하다.
- AWS STS 활용하여 임시자격이 발급되므로, 일정 시간이 지나면 자격이 비활성화 된다.
만약 크리덴셜이 유출되더라도 임시자격이어서, 영구 자격에 비해 위험성이 현저히 줄어든다.

그러나

- 크리덴셜이 안전한 공간에 암호화 되어 있고, 임시자격으로 유효시간이 있으나 여전히 로컬에 저장되기 때문에 유출되어 악용될 위험이 있다.
- AWS 에서만 사용가능하며, AZURE, GCP 등에서는 사용할 수 없다.

2. HashiCorp Vault

  AWS VAULT 가 AWS 에서만 사용가능 하고, 사용자의 PC 로컬에 인증정보를 저장하는 것이라면, 하시코프(HASHICORP) VAULT 는 AWS, AZURE, GCP 모두 사용가능하고, 인증정보를 별도로 구성된 중앙서버에 저장하는 방식이다.

AWS VAULT 와 달리 중앙서버에 인증정보를 저장하므로, 로컬 PC 를 분실, 해킹되더라도 인증정보가 안전하다. 뿐만 아니라 유효한 요청에 대해 임시 아이디, 패스워드를 발급하고 일정 기간이 지나면 삭제한다. 유효한 요청인지 아닌지 확인은 사용자의 증명서(클라우드 토큰, k8s 토큰 등) 제출을 통해 확인하게 된다.

다만 인증정보를 저장할 별도의 중앙 서버를 만들고, 이 서버와 통신할 네트워크 구성을 하는데 어려움이 있다. 주로 규모가 큰 조직에서 사용한다.

3. AWS Security Token Service (STS)

  AWS 의 임시보안 자격 증명을 의미하며, 인증 시 영구적으로 사용할 수 있는 access key 와 달리 AWS STS 는 일정 시간(설정된 시간) 동안에만 특정 자격을 부여받고, 설정한 시간이 지난 후에는 만료되어 사용할 수 없다.

IAM USER 로 로그인하면 ACCESS KEY, SECRET KEY, SESSION TOKEN 을 얻는 것처럼, AWS STS 로 ACCESS KEY, SECRET KEY, SESSION TOKEN 을 얻는다. 그리고 IAM 처럼 AWS STS 도 ROLE 을 통해 권한을 디테일하게 통제할 수 있다.

단점이 있다면 설정 시간 내 인증정보를 탈취 당할 경우, 부여된 권한과 함께 도용될 수 있다.
(유효 시간을 짧게하면 확률은 낮아진다.)

4.AWS IAM Identity Center (SSO)

  AWS IAM Identity Center 은 과거 AWS SSO 가 개편된 것이다. 여러개의 AWS 계정과 애플리케이션에 대한 접근 권한을 일괄 관리할 수 있다. 그러면 기존의 IAM 과 무슨 차이일까 ?
기존 IAM 이 유저 또는 그룹에 어떠한 자격 및 권한을 할당하는 것이고 AWS SSO 는 AWS 의 여러 계정, 애플리케이션에 접근 할 수 있는 권한을 할당, 통제하는 것이다.

장점으로는
- AWS Organization 과의 통합을 통한 중앙집중식 관리
(조직 내의 모든 계정을 인식하여 권한을 배포할 수 있다.)
- 외부 IDP (Identity Provider)와 연동 가능하다.
(일부만 가능하며 연동 불가능한 IDP 도 많으므로 구축 전 미리 확인해야 한다.)
- AWS STS 를 통해 임시 권한(임시 자격 증명)을 할당하므로, 설정한 시간 만큼만 할당 받은 자격(권한)을 사용할 수 있다.

단점으로는
- 첫 사용 때 초기 구성이 번거로움 (IDP 연동, 계정 및 그룹 정리 필요)
- 로컬 CLI 로 접속하면 일정 시간만 유효한 임시 ACCESS KEY, SECRET KEY, SESSION TOKEN 이 남는다. (설정 시간이 지나면 만료되어 사용할 수 없지만, 그럼에도 시간 내 탈취되면 자격이 도용 될 수 있다.)

5. IDENTITY FEDERATION (IDP 활용)

  외부 포털 및 SNS 계정에 로그인한 인증 값을 AWS 자격, 권한 할당에 활용하는 방식이다. 구글, 페이스북에 로그인 한 후 인증정보를 AWS 에 보내 자격, 권한을 할당받아 AWS 서비스를 사용하는 것이다.

AWS 에서 IDENTITY FEDERATION 을 활용하는 방법에는 두가지가 있는데,

- AWS STS 을 활용한 방법
구글, 페이스북 등에서 로그인한 인증값을 받아온 후 AWS STS 가 이를 확인하여 임시자격 증명을 발급한다. 발급한 임시자격증명으로 AWS 서비스를 이용한다.

- AWS Cognito 를 활용한 방법
구글, 페이스북 등에서 로그인한 인증값을 토큰으로 받아 Cognito 로 전달하고, Cognito 는 인증토큰 확인 후 임시자격증명 Access Key 를 발급한다. 이 키를 가지고 자격증명하여 AWS 서비스를 사용한다.

AWS COGNITO 를 쓸 때도 AWS STS 를 활용하여 임시자격증명을 발급하는데, COGNITO 와 STS 의 차이는 뭘까 ? AWS STS 가 토큰 교환만을 통한 임시자격증명을 발급받고 이를 바로 사용하는 것이라면, COGNITO 는 AWS STS 를 호출하여 발급받은 임시자격증명을 모바일 앱이나, 웹에서 AWS 자원 사용을 위해 활용한다는 차이가 있다.

표로 정리하면

	AWS STS	IDENTITY FEDERATION
활용 대상	커스텀 로직, 단순 구성	웹 및 앱 개발 등 복잡한 구성
기능	통신 로직 개발 필요	AWS SDK 에 의해 자동화
익명 사용자	지원안함	지원가능
IDP 관리	각각의 개별 IDP 마다 신뢰관계 설정 필요	여러개의 IDP 를 통합 관리 가능
추가기능	-	사용자 데이터 동기화, 분석 연동 등