AWS 보안 입문

개발자를 위한 AWS 보안 활용

Rahul Singh

Technical Product Manager

강의 선수 조건

기본적인 AWS 보안 지식
클라우드 컴퓨팅 개념 이해
AWS 보안 및 비용 관리 개념

AWS 보안 및 비용 관리 개념 강의 타이틀 카드

강의 목표

신원(Identity): 누가 호출하는가
권한 부여(Authorization): 무엇에 접근할 수 있는가
비밀 정보와 암호화: 데이터 보호
증거(Evidence): 사후에 무슨 일이 있었는지

강의에서 다루는 네 가지 영역을 세로로 쌓은 네 개의 번호 띠. 첫 번째 띠는 신원(Identity)으로 1장 표시. 두 번째 띠는 권한 부여(Authorization)로 2장 표시. 세 번째 띠는 비밀 정보와 암호화로 2장과 3장 표시. 네 번째 띠는 증거(Evidence)로 3장 표시. 왼쪽의 주황색 화살표는 이 영상이라는 라벨과 함께 첫 번째 띠를 가리킴.

코드는 파이프라인을 통해 배포됩니다

왼쪽에서 오른쪽으로 이어지는 흐름. 1단계, 파이프라인이라는 상자 안에 Build, Test, Deploy 세 단계가 순서대로 표시됨. 2단계, 사용자라는 상자에서 git push라고 적힌 화살표가 파이프라인으로 들어감. 3단계, 파이프라인 아래에 매달린 주황색 배지에 its own identity라고 표시됨. 화살표가 파이프라인에서 AWS라는 상자로 이어짐.

먼저, 용어 하나를 짚고 넘어가겠습니다

파이프라인은 코드를 빌드, 테스트, 배포하는 자동화 프로세스입니다
푸시 시 자동으로 실행되며, 사람의 개입이 없습니다

엉뚱한 이유로 실패하는 배포

코드를 변경하면 실제로 누구의 권한이 검사될까요?

변경 사항을 푸시합니다

세로 흐름의 1단계. 사용자라는 상자가 코드 변경 사항을 푸시함.

엉뚱한 이유로 실패하는 배포

코드를 변경하면 실제로 누구의 권한이 검사될까요?

변경 사항을 푸시합니다
파이프라인이 실행됩니다

세로 흐름. 1단계, 사용자가 코드 변경 사항을 푸시함. 화살표가 아래로 이어져 2단계, 파이프라인이 배포를 실행함.

엉뚱한 이유로 실패하는 배포

코드를 변경하면 실제로 누구의 권한이 검사될까요?

변경 사항을 푸시합니다
파이프라인이 실행됩니다
배포가 중단됩니다: AccessDenied

가장 먼저 드는 생각: "내 권한을 확인해 봐야겠다."

세로 흐름. 1단계, 사용자가 코드 변경 사항을 푸시함. 2단계, 파이프라인이 배포를 실행함. 3단계, AWS가 요청을 평가하고 AccessDenied를 반환함.

실제로 일어난 일

왼쪽에서 오른쪽으로 이어지는 흐름의 1단계. 사용자라는 상자로, 관여는 여기서 끝남.

푸시합니다. 관여는 여기서 끝납니다

실제로 일어난 일

왼쪽에서 오른쪽으로 이어지는 흐름. 사용자라는 상자에서 파이프라인이라는 상자로 화살표가 이어짐. 파이프라인 아래에 deploy-role이라는 배지가 매달려 있음.

푸시합니다. 관여는 여기서 끝납니다
파이프라인이 배포하며, 팀이 만든 역할로 실행됩니다

실제로 일어난 일

사용자에서 파이프라인, 다시 AWS로 이어지는 흐름. 파이프라인 아래에 deploy-role이라는 배지가 매달려 있고, checks라고 적힌 점선 화살표가 사용자가 아닌 그 배지로 돌아감.

푸시합니다. 관여는 여기서 끝납니다
파이프라인이 배포하며, 팀이 만든 역할로 실행됩니다
AWS가 그 역할을 평가합니다

행위자와 보안 주체

행위자(Actor)

작업을 시작시킨 주체입니다.

여기서는: 사용자.

작업을 시작시키는 행위자를 나타내는 사람 형상 아이콘.

행위자와 보안 주체

행위자(Actor)

작업을 시작시킨 주체입니다.

여기서는: 사용자.

보안 주체(Principal)

요청이 도착했을 때 AWS가 평가하는 자격 증명입니다.

여기서는: 파이프라인의 역할.

작업을 시작시키는 행위자를 나타내는 사람 형상 아이콘.

보안 주체를 나타내는 아이콘.

행위자와 보안 주체

행위자(Actor)

작업을 시작시킨 주체입니다.

여기서는: 사용자.

보안 주체(Principal)

요청이 도착했을 때 AWS가 평가하는 자격 증명입니다.

여기서는: 파이프라인의 역할.

Lambda: 실행 역할. ECS: 태스크 역할. 이름은 다르지만 보안 주체는 동일합니다
예외: 터미널에 장기 키가 있다면 IAM 사용자가 보안 주체가 됩니다

작업을 시작시키는 행위자를 나타내는 사람 형상 아이콘.

AWS가 행위자가 아닌 보안 주체를 확인하는 모습을 보여주는 아이콘.

동일한 배포, 서로 다른 두 역할

역할 A (AdministratorAccess의 형태)

모든 버킷 읽기
모든 키 사용
모든 함수 업데이트

역할 B

버킷 하나 읽기
키 하나 사용
함수 하나 업데이트

프리픽스(Prefix): 버킷 내부의 폴더와 유사한 경로

여섯 가지 정책에 모두 접근할 수 있는 전체 접근 역할을 보여주는 이미지.

정책 하나에만 접근할 수 있는 제한된 접근 역할을 보여주는 이미지.

피해 범위(Blast Radius)

광범위한 역할

탈취될 경우: 계정 내 모든 버킷, 프리픽스, 객체에 접근할 수 있습니다.

제한된 역할

탈취될 경우: 버킷 하나, 프리픽스 하나에만 접근할 수 있습니다. 그 이상은 없습니다.

계정 전체의 모든 부분에 접근하는 광범위한 역할을 보여주는 동심원 이미지.

제한된 역할이 가장 안쪽의 객체와 프리픽스 원에만 접근하고 나머지 부분은 건드리지 않음을 보여주는 동심원 이미지.

최소 권한 원칙, 실제 적용

역할은 업무에 필요한 만큼만 수행해야 하며, 그 이상은 지양해야 합니다.

AWS 관리형(예: AmazonS3ReadOnlyAccess)은 모든 버킷에 접근합니다. 고객 관리형은 프리픽스 하나까지 직접 설정할 수 있습니다
접근 범위와 수명 관리: 장기 키보다 단기 자격 증명을 사용하세요
AWS는 인프라를 보호합니다
역할의 범위를 얼마나 넓힐지는 사용자의 결정이며, 이는 저장소(Repository)에 반영됩니다

예시: reports-bucket 읽기 역할 허용 항목 두 개뿐, 그 외에는 아무것도 부여하지 않습니다.

누가 무엇을 할 수 있는지 결정하는 서비스인 IAM에는 아무것도 추가하지 않습니다

역할의 권한 목록에서 불필요한 권한 세 개는 빨간색으로 취소선이 그어져 있고, 필요한 권한 두 개는 초록색으로 유지됨.

연습해 봅시다!

개발자를 위한 AWS 보안 활용