[AWS][IAM][AssumeRole] 다중 계정을 고려한 사용자 관리
6817 단어 IAMAWSAssumeRole
아래의 범위로 쓰여 있습니다.
(계좌 수는 적지만 앞으로 늘어날 때 더욱 쉽게 전개되기를 바란다)
역할 전환 방식의 권한 설정 그룹 만들기
https://qiita.com/batatch/items/08aa3f705336a0fea89e
역할 전환에 대한 사용자 만들기, MFA 인증 활성화
https://qiita.com/batatch/items/9bebb1710e26960075b6
방식 토론
다중 계정 사용자 관리는 몇 가지 방식이 있는데 다음 글에서 간단하고 알기 쉽게 정리했다.
AWS 다중 계정 관리 및 로그인 중앙 집중식 설계
https://blog.takuros.net/entry/2020/12/01/094417
계좌 수가 적거나 대리 결제 회사를 사용할 때 AWS Organizations의 사용이 적합하지 않을 수 있습니다.
스텝 형식에서 사용자, 그룹 등록을 대표 AWS 계정(이하 주 계정)에 통합하고 대상의 AWS 계정(이하 대상 계정)에 역할을 등록하여 AWS 계정을 뛰어넘어 역할(역할 교환)을 전환합니다.
아래의 글은 이해하기 쉽다는 것을 설명한다.
AWS 다중 계정의 IAM 사용자 설계 전략 검토
https://iselegant.hatenablog.com/entry/2020/05/24/215808
이 부근을 읽으면 개요를 잡을 수 있다.
..하지만 실제로 적용하면 무엇을 설정해야 할지 모르기 때문에 자신이 실시한 일을 정리해 보자.
프로비저닝
캐릭터 전환에 대해 그림을 그려 보세요.
등장인물은 이런 느낌이다.
마스터 계정
또 다음과 같은 용어도 자주 등장한다.
상하문에 따라 같은 일이나 미묘하게 다른 혼란을 가리킨다.
역할 전환
역할의 비헤이비어 전환
보조 역할
역할 전환을 위한 AWS의 구조, 기능
참고로 캐릭터 전환에서 IAM이 설정한 사용자, 그룹, 캐릭터, 전략 등 요소가 복잡하게 실현되기 때문에 각 요소에 대해 잘 정리하는 것이 좋다.
나는 각 요소의 연관성을 다음과 같이 그릴 수 있다고 생각한다.
권한 자체를 정의하는 것은 정책이고 정책의 링크 대상은 사용자(, 그룹) 또는 역할입니다.
메커니즘에서 역할은 사용자와 직접 연결되는 것이 아니라 역할을 분배한 가상 사용자(AssumedRoleUser)로 대체된다.
아바타, 인형, 의인화 같은 거요?
아이콘은 투구의 그림이고 임무를 나타내는 모자인가.
이런 형식이라면 권한의 보유 방법은 캐릭터 정의에만 집중되기 때문에 사용자(, 그룹)가 어떤 캐릭터로 전환할 수 있는지만 설정하면 전망이 좋아진다.
또한 캐릭터가 분배되는 것이 아니라 의인화된 형식이기 때문에 여러 캐릭터로 전환할 수 있어도 권한의 합성이 되지 않는다.
역할 전환 구성에서 작업은 다음과 같습니다.
로그인한 곳이 하나밖에 없기 때문에 조작이 간단해졌다.
AWS 계정을 왕복하는 것도 메뉴에서 선택할 수 있기 때문에 (첫 번째, 등록 수속 필요) 편합니다.
하지만 안타깝게도 여러 계정의 화면을 동시에 열려면 브라우저의 세션이 공유되기 때문에 탭에서 동시에 열 수 없습니다.
나는 모든 AWS 계정의 Chrome 사용자를 위해 세션을 구분합니다.
사용자 로그인 설정
역할 전환을 통해 사용자 등록을 주 계정에 집합할 수 있기 때문에 다음은 사용자 등록에 관한 것입니다.
메인 계정에 IAM 사용자를 등록하고 MFA 인증을 사용하기 위해 다른 설정을 하고 싶습니다.
AWS: IAM을 사용하면 보안 자격 증명 페이지에서 콘솔 암호를 관리할 수 있습니다.
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_aws_my-sec-creds-self-manage-password-only.html
AWS: MFA 인증을 받은 IAM 사용자는 보안 인증 정보 페이지에서 자신의 MFA 장치를 관리할 수 있습니다.
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.html
이러한 정책을 부여하는 공동팀을 마련해 전 IAM 사용자가 속한 형식을 쉽게 이해할 수 있도록 했다.
역할 계획
각 대상 계정에 대한 역할이 준비됩니다.
주 계정은 역할 x 목표 계정의 전환 그룹이 필요하기 때문에 너무 세분화되거나 각 계정을 대상으로 하면 관리가 복잡해진다.
위에서 열거한 참고 문헌 등을 보면 모든 계좌를 공통된 역할로 통일하는 것이 좋다.
계정 1
계정2
계정3
...
Administrator
a1_Admin
a2_Admin
a3_Admin
...
Maintainer
a1_Maintain
a2_Maintain
a3_Maintain
...
Developer
a1_Develop
a2_Develop
a3_Develop
...
:
:
:
:
...
AWS는 각 직무 기능에 대한 정책 정의를 미리 준비했기 때문에 이를 바탕으로 설정하는 것이 좋습니다.
관리자 역할에는 관리자 액세스 정책 설정이 포함됩니다.
AWS: 직무 기능 AWS 관리 정책
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_job-functions.html
예제
인프라 코드
인프라 시설의 설정이 가능하다면 인코딩하고 싶습니다.
화면 조작에서 설정하면 잊어버리고 절차서 등 어떤 정보를 공유해야 한다.
어차피 하려면 실행할 수 있는 코드가 좋아요.
방법이 많습니다. Hashi Corp사의 Terraform은 고정된 것 같습니다.
Terraform
https://www.terraform.io/
이번 사용자 설정도 Terraform으로 인코딩됩니다.
사용자 설정은 AWS 계정 자체의 초기 설정이기 때문에 Terraform의 코드는 어디에서 실행됩니까?고민하다.
AWS Cloud Shell
https://aws.amazon.com/jp/blogs/news/aws-cloudshell-command-line-access-to-aws-resources/
브라우저에서 Shell 명령을 사용할 수도 있고 AWS API 등을 클릭할 수도 있습니다.
관리자를 위한 대체 IAM 사용자를 만들고 Cloud Shell에서 terraform을 실행하여 사용자를 설정합니다.
사용자를 설정한 후 버려진 사용자를 삭제하면 코드 관리의 모든 IAM 사용자가 사용할 수 있습니다.
이번에는 여기까지.
길어졌기 때문에 설치편은 따로 적어 두었다.
//EOF
Reference
이 문제에 관하여([AWS][IAM][AssumeRole] 다중 계정을 고려한 사용자 관리), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/batatch/items/425661dbffece3b981bf텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
