[Secworkshop] Access Delegation(권한 위임)
AWS의 Security Workshop 1번째 Access Delegation(권한 위임)에 대해서 알아보자.
직무분리와 최소권한의 원칙. ISMS 시험 등을 보면 많이 들어오는 단어이다.
그 뜻은 개발자 vs 운영자 등과 같이 가 직무를 분리하고, 각 직무마다 딱 필요한 권한만 부여하여
권한의 오남용을 사전에 예방하기 위함입니다.
AWS는 서버 담당자가 확인해야 하는 서비스와 보안 담당자가 확인해야 하는 서비스 등이 서로 다르기때문에
각 사용자 그룹마다 서로 다른 서비스 허용 정책을 설정하는 것이 중요한 포인트이다.
AWSSecWorkshop을 통해 하나씩/한단계씩 진행하는 것이 목표이다.
- Workshop에 기재 된 내용을 따라가면서 내재화하고, 정리하는것이기에 일부 내용이 다를 수 있다.
시나리오 - 아이덴티티 라운드 로빈 (awssecworkshops.com)
Scenario - Identity Round Robin
Access Delegation Round Welcome to the world of Access Delegation! Imagine that you are an AWS "Super User" who is in charge of your organization's AWS account. You have heard about services such as Amazon GuardDuty, Inspector, and Macie that can help you
identity-round-robin.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)
AWS IAM 사용자 계정 생성 방법
AWS 계정을 처음 만들면, 루트(이하 Root) 사용자로 로그인을 하고 모든 서비스에 대한 읽기/수정 권한을 받는다. 개인이 사용하는 용도라면 Root 계정만 있어도 무방하겠지만, 기업에서 사용하는
dobby-isfree.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 하나 끝!!!