Architecting on AWS 모듈 2 (보안)

보안

카페를 운영한다고 생각해보자.

root user로 접속을 하면 보안 상 좋지 않다. admin 권한을 가지고 있는 IAM user를 만들어서 사용하는 것이 좋다.

점주가 root user라면 관리자는 IAM user인 것이다.

IAM user - 가장 기본적인 보안 주체

 

 

IAM에는 user, group, role이 있다.

ID, Password는 콘솔로 로그인하는 방법이고, Secret Key, Secret Access Key로는 SDK나 CLI를 통해 로그인할 수 있다.

IAM은 그룹이 그룹을 포함할 수 없다. 

Role은 임시 권한을 주는 방법이라고 생각하면 된다.

Policy는 보안 주체 리소스 액션을 허용할지 거부할지 명세하는 JSON 문서이다.

 

최대 권한 설정과 권한 부여의 교집합을 실제 보안 주체가 접근할 수 있다.

IAM 자격 증명 기반 정책 - 주체가 접근할 것에 대한 정책

IAM 리소스 기반 정책 - 누가 이 리소스에 접근할 것인지에 대한 정책

 

AWS 관리형 정책은 이미 있는 걸 가져다 쓰면 된다.

고객 관리형 정책은 이미 있는 것에서 내가 변형을 해서 쓰는 것이다.

 

 

이런 식으로 설정할 수 있다.

 

이런 유저가 있다고 하자

user는 명시적 허용때문에 인스턴스를 시작할 수 있다.

그러면 user는 인스턴스를 중지할 수 있을까? -> 명시적 거부(거부됨을 써둠) 때문에 중지할 수 없다. -> 명시적 거부가 먼저 평가됨을 알 수 있다.

user는 DynamoDB에 대한 접근이 가능할까? -> 암시적 거부(써두지 않음) 때문에 접근할 수 없다.

 

상위 계층에 SCP를 설정하면 하위 계층에도 영향을 준다.

 

교집합만 허용이 된다.

 

확인 문제

사용자, 그룹 또는 역할에 연결할 수 있는 것은?

- 자격 증명 기반 정책(IAM 정책)

 

보안 주체에 할당되지 않고 특정 리소스에 액세스 하는 권한을 부여할 수 있는 정책 유형은?

- 리소스 기반 정책

 

역할을 사용하는 이점?

1. 교차 계정 액세스 권한을 부여할 수 있음

2. 임시 권한을 부여하여 보안을 강화함

 

루트 사용자는 일상적인 AWS 관리 업무에 사용하면 안 된다.

- 참

 

Active Directory, AWS 계정 및 서브 파티 서비스를 사용하여 고객의 로그인을 단순화하는 것?

- AWS SSO

 

정리

명시적 거부 -> 명시적 허용 -> 묵시적 거부 순으로 먼저 평가된다.