[클라우드 인프라와 API의 구조] 9. 인증과 보안

HTTPS

HTTP over SSL/TLS

API에서 사용하는 HTTP에서는 통신 내용이 평문으로 전달돠기 때문에 도청을 할 경우 주고 받는 정보가 유출될 수 있음. 따라서 중요한 메타 데이터가 오고 가는 클라우드 환경에서는 HTTPS를 하는 것이 일반적임.

 

HTTPS의 동작 방식

443번 포트 번호를 사용하며, TCP/IP에 OSI 참조 모델 L5의 SSL/TLS를 적용하고 전자 인증서릍 통해 통신 쌍방의 신뢰관계를 만드는 방식.

HTTPS는 데이터의 암호화뿐만 아니라 위변조를 방지하고 접속하려는 URI가 신뢰할 수 있는 상대의 것인지를 확인하는 기능도 갖추고 있음.

 

인증서

인증서는 서버 인증서와 클라이언트 인증서로 분류한다

클라우드 환경에서는 클라우드가 신뢰할 수 있다는 것을 증명하기 위해 인증서가 필요한대, 클라우드의 엔드포인트가 서버 측에 있으므로 서버 인증서가 활용됨.

 

사용자

사용자에 대한 인증을 처리하는 컴포넌트는 AWS는 IAM(Identity and Access Management)이 담당.

 

테넌트

클라우드에는 최상위 개념으로 테넌트가 존재. (AWS에서는 Account로 표현)

하나의 테넌트는 또 다른 테넌트와 완전히 격리되어 있어서 원칙적으로 여러 테넌트에 걸쳐서 어떤 작업을 하는 것은 불가능함. (예외적으로 설정을 확장하는 방법도 있음)

 

사용자

API를 실행하게 만드는 사람을 의미.

사용자도 리소스 형태로 분류되기 때문에 API를 통해 생성, 변경, 삭제를 할 수 있음.

클라우드에는 테넌트와 연결된 특별한 관리자 계정이 존재. (리눅스로 치면 root)

처음에는 이 관리용 계정을 사용자처럼 사용해서 리소스를 생성함. 하지만 실제 운영시에는 사용하지 않도록 권장하고 있음.

 

그룹

여러 사용자를 그룹으로 묶어두면 그룹 단위로 정책을 할당할 수 있으므로 사용자별로 정책을 적용시키는 것보다 작업 시간도 줄어들고 정책 관리도 효율적으로 할 수 있음.

 

정책

권한을 제어할 때 사용하는 기능.

클라우드에서는 많은 컴포넌트나 액션 API, 리소스가 존재 ⇒ 통제가 필요한 대상에는 정책을 적용하여 접근이나 실행을 제한하도록 만들어야 함.

정책은 JSON 형식으로 정의되는데 기본적으로 API를 제어함. (권한을 제어한다는 것은 곧 API의 접근과 실행을 제어한다는 것과 같음)

 

AWS IAM 정책의 기본 요소

AWS IAM에서 사용 가능한 정책의 기본 요소는 Effect, Action, Resource로 구성.

 

Effect

• 허가인 경우 Allow, 거부인 경우 Deny

Action

• 허가하거나 거부할 액션 API를 기재

Resource

• 허가하거나 거부할 리소스를 ARN 형식으로 기재

{
	"Version": "2021-04-08",
	"Statement": [
		{
				"Sid": "정책문ID",
				"Effect": "Allow",
				"Action": "컴포넌트명:API명",
				"Resource": "리소스명(ARN)",
				"Condition": "조건"
		},
		{
				"Sid": "정책문ID",
				"Effect": "Deny",
				"Action": "컴포넌트명:API명",
				"Resource": "리소스명(ARN)",
				"Condition": "조건"
		}
	]
}

 

• 아무것도 지정하지 있지 않다면 묵시적인 거부로 인식.
• 명시적인 Deny > 명시적인 Allow > 묵시적인 Deny의 우선순위로 적용됨.

 

인증 키와 토큰

인증 키

AWS에서는 콘솔에서는 IAM 사용자의 패스어드로 인증하지만, API나 CLI, SDK를 사용할 떄는 IAM의 ID에 상응하는 액세스 키와 시크릿 액세스 키를 사용하게 됩니다.

 

토큰

보안 상의 이유로 클라우드 서비스에서는 유효 기간이 있는 임시 패스워드를 발급하는 방식을 사용 (토큰)

AWS에서는 STS라는 서비스가 임시 자격 증명이라는 토큰을 발급.

 

서명

AWS와 같이 엔드포인트가 외부에 공개된 클라우드에서는 보안을 위해 HTTPS를 사용하여 통신함.

그와는 별개로 클라이언트가 실제로 존재하는 클라이언트인지 확인하거나, 클라이언트로부터 전송된 데이터가 위변조되지는 않았는지를 확인하는 방법도 필요 ⇒ 전자 서명 사용.

CLI, SDK를 사용하는 방식은 이러한 처리가 내부적으로 이루어져 따로 전자 서명을 쓸 필요가 없지만, API를 직접 사용한다면 전자 서명에 의존할 수 밖에 없음.

 

전자 서명의 구조와 동작 방식

API를 실행할 때 생성되는 HTTP 요청을 전자 서명하기 위해서는, 우선 요청 정보의 해쉬값과 요청 값, 시크릿 액세스 키를 조합해서 전자 서명을 만들어야 함.

이떄 사용하는 알고리즘은 SHA을 사용.

서명 값은 필요한 서명 키와 서명 문자열을 HMAC 함수를 사용해서 얻어냄. (시크릿 액세스 키와 페이로드 필요)

최종적으로 만들어진 서명 값을 HTTP 헤더의 Authorization에 설정되어 API를 실행할 때 전자 서명이 이루어짐.

 

IAM 롤과 리소스 기반 정책

클라우드 환경에서는 리소스에 정책을 할당할 수 있는 기능이 필요한대 이때 IAM 롤과 리소스 기반 정책이 필요함.

IAM 롤을 부여 받은 리소스는 인증 키가 없어도 API를 실행할 수 있는데 이유는 IAM 롤을 할당하는 과정에서 내부적으로 STS가 이미 사용되어 토큰을 발급했기 때문.

 

복수 테넌트에 대한 제어 권한

테넌트는 다른 테넌트와 격리되어 있고 AWS에서는 인증 관련 리소스가 테넌트에 속하므로 테넌트를 넘나드는 작업은 불가능함. 단 예외적인 방법이 있음 ⇒ 정책을 통해 권한을 부여하면 여러 테넌트를 제어할 수 있음.

AWS에서는 관리자용 계정과 IAM 사용자를 구분.

한 테넌트의 관리자 게정으로는 다른 테넌트의 컴포넌트를 제어할 수 없음.

그럼에도 불구하고 다른 테넌트의 리소스에 접근해야 하는 경우에는 IAM 롤의 Principle에 접근을 허용할 테넌트의 어카운트, 혹은 계정 번호를 지정한 후, AssumeRole의 API를 실행하여 해당 테넌트로부터의 접근을 허용하게 만들 수 있음. ⇒ Cross-Accounts access 접근이라고 함.

 

페더레이션

토큰을 활용하는 방법 중에는 제 3의 ID에 권한을 위임하는 페더레이션이라는 방식이 존재.

예시로 구글, 아마존 등에서는 ID로 통합 인증 (Single Sign On)을 제공.

통합 인증 방식에는 크게 SAML, OIDC 등으로 접속하는 방식과 WebID로 페더레이션을 하는 방법이 있음.

 

SAML

• 인증과 인가에 관련된 각종 정보들을 기술하는 마크업 언어. SAML을 HTTP/HTTPS를 통해 주고 받으면 통합 인증이 되는 셈인데 이때 필요한 SAML 메타 데이터는 클라우드 측에서 제공.

OIDC

• OAuth 2.0을 채용하여 웹 API를 통한 접근을 제어하는 방법. OpenID가 제공하는 인증 정보를 기반으로 다른 ID와 ID 프로바이더 간의 신뢰 관계를 형성.