AWS의 Security Workshop 1번째 Access Delegation(권한 위임)에 대해서 알아보자.
직무분리와 최소권한의 원칙. ISMS 시험 등을 보면 많이 들어오는 단어이다.
그 뜻은 개발자 vs 운영자 등과 같이 가 직무를 분리하고, 각 직무마다 딱 필요한 권한만 부여하여
권한의 오남용을 사전에 예방하기 위함입니다.
AWS는 서버 담당자가 확인해야 하는 서비스와 보안 담당자가 확인해야 하는 서비스 등이 서로 다르기때문에
각 사용자 그룹마다 서로 다른 서비스 허용 정책을 설정하는 것이 중요한 포인트이다.
AWSSecWorkshop을 통해 하나씩/한단계씩 진행하는 것이 목표이다.
- Workshop에 기재 된 내용을 따라가면서 내재화하고, 정리하는것이기에 일부 내용이 다를 수 있다.
시나리오 - 아이덴티티 라운드 로빈 (awssecworkshops.com)
이번 Workshop에서는 어떻게 서비스 권한을 분리/추가하는지와 어떻게 모니터링하고 점검하는지에 대해서 알아보자
□ 시나리오 목적
각 AWS 사용자 그룹별로 서로 다른 서비스 권한을 부여하고, 권한 오남용 등에 대한 모니터링 방안 수립
□ 시나리오 준비들
열정.. 열의.. 그리고 의지. 사실 별 다른 준비가 필요하지 않다. 시나리오 F/U하며서 내재화하면 된다.
□ 시나리오 아키텍처(목표)
□ 시나리오 빌드
1. AWS 로그인 후, AWS Macie 서비스 시작한다.
- Macie 서비스를 통해 민감한 정보(로그인 정보 등등)을 S3 Bucket에 저장하고,대규모 검색을 가능하게 해준다.
- 년/월/일 단위로 S3 Bucket에 저장되며, 정규표현식을 통해 사용자 정의 데이터를 검색할 수 있다.
- 자세한 내용은 아래 페이지에서 확인할 수 있다.(아직.. 하진 않았지만)
2. AWS GuardDuty 서비스 시작한다.
- GuardDuty 서비스는 VPN, CloudTrail, S3 데이터에 악의적인 IP 또는 사용자 접속하는지 모니터링하는 서비스이다.
- 결과에 따라 0 ~ 10 심각도의 결과를 얻을 수 있으며, 심각도가 높을수록 위험도가 높음을 뜻한다.
- 사용자 로그인 및 권한 추가/회수의 데이터가 저장되는 S3 Bucket에 악의적인 사용자가 접속하는지 모니터링하기 위함이며
꼭 사용해야하는 서비스는 아니다. 돈을 주고 자동화된 모니터링 서비스를 이용하는 것이다.
- 자세한 내용은 아래 페이지에서 확인할 수 있다.(아직.. 하진 않았지만)
결론적으로는 Macie 서비스 + GuardDuty 서비스를 같이하여
사용자 로그인 정보 또는 권한 추가/회수에 대한 로그를 S3 Bucket에 저장 한 다음하고 이를 모니터링 한다.
3. CloudFormation 스택 만들기를 한다.
- workshop에 나와있는 Deploy 버튼 클릭 후 다음 > 다음 > 다음을 클릭하면 자동으로 스택이 생성된다.
- CloudFormation 서비스에서는 AWS 리소스를 한번에 정해진 템플릿으로 배포할 수 있는 스택을 만들 수 있다.
- 매번 서버 용량/IAM 권한 부여/스토리지 설정등을 할 수 없기에 스택을 만들고 이를 활용한다.
스택은 AWS 리소르를 배포하기 위해 미리 정의 된 양식으로 보면 된다.
- CloudeFormation을 통해 스택을 호출하게 되고, 스택에 정의된 텍스트를 통해 리소스를 배포(생성)한다.
- 스택 생성 이후, 템플릿을 보면 아래와 같이 각 Role에 대한 서비스 권한 부여가 미리 정의되어 있음을 알 수 있다.
또한 스택의 템플릿을 보면 아래와 같이 CloudTrail 서비스를 Loggin하기 위한 S3 bucket이 생성됨을 알 수 있다.
실제로 S3 서비스를 들어가면, 아래의 S3 Bucket이 하나 생성되어 있고,
S3 Bucket이름을 선택하면, 년/월/일 단위의 폴더가 있으면서 최종적으로는 CloudTrail 로그를 볼 수 있다.
지금까지의 상황을 보면
CloudFormation을 통해 스택을 만들고 > 스택을 통해 정형화 된 IAM Role을 만들고 > 계정의 Role을 감시/모니터링할 수 있는 CloudTrail/S3 Bucket을 만들었다.
그러면, 이제 Role을 만들었으니깐 실제 이번 Workshop에서 하고자 했던 권한을 위임해보자!!
4. IAM 서비스 > 역할 > SecAdministrator을 검색해서 해당 Role에 부여 된 권한을 확인한다.
- 위 스택에서 만들었던 템플릿과 동일하게 IAM Role이 만들어지고, 권한이 부여된것을 확인할 수 있다.
- 그리고 아래와 같이 각 Role마다 필요한 권한을 추가할 수도 있고, 삭제할 수도 있다.
※ 정책 연결에서는 해당 Rold에 이미 만들어진 정책을 추가할 수 있다.
※ 인라인 정책 추가에서는 읽기/쓰기 등의 세부 액션에 대한 각 개별 서비스 권한을 추가할 수 있다.
※ 정책 또는 권한 추가 시에는 서비스 클릭 또는 JSON 포맷으로 코딩하는 방식으로 추가가 가능하다.
5. Operation 정책이 할당 된 계정을 Admin 계정으로 역할 전환하기 준비
- 역할 전환을 하기 위해서는 기본적으로 IAM 테스트 계정을 만들어야 한다. 만드는 방법은 아래 게시물 참고한다.
AWS IAM 사용자 계정 생성 방법 :: 평범한 직장인의 평범한 블로그 (tistory.com)
- 역할을 전환하기 위해서는, 먼저 어떤 계정에게 역할을 부여할 수 있을지 신뢰관계를 등록해야 한다.
- IAM > 역할 > SecAdmin 역할 > 신뢰관계 > 신뢰관계 편집 선택해서, 신뢰관계를 편집하자
→ 쉽게 말하면, 해당 권한을 신뢰관계에 있는 계정이 사용할 수 있도록 편집해주는 것이다.
- 신뢰관계를 편집하고 나면, 아래와 같이 신뢰할 수 있는 개체가 추가 되었음을 알 수 있다.
5. Operation 정책이 할당 된 계정을 Admin 계정으로 역할 전환하기
- IAM 계정으로 로그인 후, 우측 상단의 계정 정보를 선택하면 역할 전환 버튼이 있다.
- 그리고 계정/역할/표시이름을 선택하면 해당 역할로 권한이 변경 된다.
→ 계정 : Root ID
→ 역할 : 내가 변경할 역할 Full name을 적어주면 된다. IAM > 열할에서 그대로 복사하면 된다.
→ 표시이름 : 역할 변경 후, 우측 상단에 표시할 이름이다. 간단하게 말하면 그냥 태그?
- 위 과정을 모두 끝내고 나면, 아래와 같이 역할 전환이 된다!!
- Secadmin의 표시 이름이 생겼으며, 내가 어떤 역할로 전환되어 있는지까지 보여준다.
역할 전환을 하고 나면, test123의 역할이 일시적으로 SecAdministrator 권한으로 변경이 되며
해당 역할에서 부여받은 서비스/권한을 모두 이용할 수 있다.
예를들어) test123은 IAM 서비스 권한이 없지만, 일시적으로 Secadmin 권한을 받아 IAM 수정 가능함
그렇다면, 한번 역할이 전환되면 무제한으로 해당 역할을 사용할 수 있을까? 답은 No! 이다.
IAM > 역할 > 해당 역할을 선택하면 최대 세션 지속 시간이 정해져있다.
즉, 해당 시간 이후에는 자동으로 본래의 역할로 전환 된다는 의미이다.
클라우드 실무를 아직 해보진 않아서, 정확히 역할 전환을 하는 사유와 의미를 유추해보긴 힘들지만
내 생각은 영구적으로 특정 서비스 권한은 필요없으며, 단기적으로 권한이 필요한 경우에는 역할 전환 기능을 사용하는 것 같다.
또한, 지금은 IAM 계정에서 역할 전환을 하였지만, EC2/정책/서비스 등 모든 부분에 대해서 역할 전환이 가능하다.
IAM Securityworkshop 하나 끝!!!
'기술 이모저모 > [AWS] Workshop' 카테고리의 다른 글
[Secworkshop] Using AWS Cognito (0) | 2022.02.02 |
---|---|
[AWS][API Gateway][Lambda] API 서비스 이론만 알아보기 (0) | 2022.02.01 |
[AWS][Cognito] Cognito 사용자 인증 서비스 개념 (0) | 2022.01.31 |
[AWS][IAM] IAM 계정 로그인 (0) | 2022.01.30 |
[AWS][IAM] IAM 사용자 계정 생성 방법 (0) | 2022.01.30 |