IAM - 정책 평가 로직
IAM 권한 경계(Permissions boundary)
- IAM 권한 경계란
IAM 개체의 최대 권한을 정의한느 고급 기능 - 권한 경계는 사용자와 역할만 지원, 그룹은 지원 X
- 예시
- S3, CloudWatch, EC2를 모두 허용한다.
이것을 IAM 사용자에 연결하면 권한 경계를 설정하는 것.
==> S3, CloudWatch, EC2 내의 작업만 가능
- 추가로 IAM 정책을 통해 IAM 권한을 지정해야 한다.
iam:CreateUser 액션과 * 리소스를 같은 사용자에 연결
==> 권한 경계와 IAM 정책을 통한 권한이 완성된다.
- 그러나 최종적으론 아무 권한도 생기지 않는다.
왜?
IAM 정책은 IAM 권한 경계 밖에 있기 때문에 사용자가 다른 IAM 사용자를 생성할 수 없다.
- 그럼 어떻게 해야할까?
IAM 권한 경계를 생성하기 전에 사용자를 생성한다.
- 예를들어 새로운 사용자를 생성하고 그 사용자에게 AdministratorAcess를 부여하더라도 IAM 권한 경계에 AmazonS3FullAccess를 지정했다면 S3 내부에만 액세스 가능하게 된다. - IAM 권한 경계는 AWS Organizations SCP와 함께 사용될 수 있다.
- 도식에 유효 권한이 사용자나 그룹에 부여된 자격 증명 기반 정책과 그룹이 아닌 사용자나 역할에만 적용되는 권한 경계와 계정상 모든 IAM 개체에 적용되는 Organizations SCP 중앙에 있다.
- 사용자가 주어지는 권한은 교칩합 부분인 것이다. - 사용 사례
- 관리자가 아닌 사용자에 책임을 위임하기 위해 권한 경계 내에서 새 IAM 사용자를 생성
- 개발자가 권한을 스스로 부여하고 관리하는데 특권을 남용하는 것을 막기 위해 스스로를 관리자로 만들지 못하게 하기.
- 계정에 SCP를 적용해 계정의 모든 사용자를 제한하지 않고 AWS Organizations의 특정 사용자만 제한할 수 있다.
IAM 정책 평가 논리
- AWS 내에서 액션에 대한 권한 부여 방법 도표
-----------------------------------------------------------
- Deny evaluation
가능한 모든 정책을 살펴보고 명시적으로 거부가 있다면 자동으로 거부
- Organizations SCP
허용된다고 평가되면 다음 단계로 넘어감
그렇지 안으면 암시적 거부로 거부
- 리소스 기반 정책(S3, SQS, SNS, Lambda)
S3, SQS, SNS, Lambda에 적용됐는지 평가
리소스 기반 정책이 있는지, 있다면 허용 여부에 따라 나뉨
- 자격 증명 기반 정책
자격 증명 정책이 있는지 없는지
허용이 됐는지 아닌지에 따라 암시적으로 거부되거나 다음 단계로 넘어감
- IAM 권한 경계
- 세션 정책
STS 관련 내용
- 정리: 결론적으로 특정 IAM 액션을 할 때마다 모든 방면에서 평가 된다.
IAM 정책 예시
- Action: "sqs:*,
- Effect: "Deny",
- Resource: "*"
-----------------------------------
- Actions: "sqs:DeleteQueue"
- Effect: "Allow",
- Resource: "*"
----------------------------------
- sqs:CreateQueue를 실행할 수 있는가?
답: X
이유: "sqs:*"에 CreateQueue가 포함되어있어 Deny된다. - sqs:DeleteQueue를 실행할 수 있는가?
답: X
이유: 첫 번째 블록에 모든 sqs 동작을 명시적으로 Deny했기 때문에 두 번째 블록에 Allow가 명시되어 있어도 실행할 수 없다. - ec2:DescribeInstances를 실행할 수 있는가?
답: X
이유: 명시적 거부 또는 명시적 허용도 없지만 해당 IAM 정책 내에서는 실행할 수 없다.(IAM 정책은 기본적으로 거부된다.)
IAM 자격 증명 센터(= SSO)
- AWS 조직이나 비즈니스 클라우드 애플리케이션의 모든 AWS 계정에서 Single Sign-On 할 수 있다.
즉, Salesforce, Box, Microsoft 365등에 연결 가능
또는 SAML2.0 통합이 가능한 어떤 애플리케이션에도 연결 가능 - EC2 Windows 인스턴스에 대해서도 SSO 제공
한 번만 로그인해 모든 것에 액세스 가능함 - ID 공급자
- 이 로그인을 위해 사용자는 두 위치에 저장될 수 있다.
- IAM 자격 증명 센터에 내장된 ID 저장소나, 서드파티 ID 공급자에 연결할 수 있다.
Active Directory(AD)이거나, OneLogin, Okta 등등...
- 로그인 흐름
- 로그인 페이지로 이동해 사용자 이름과 비밀번호 입력
- AWS IAM 자격 증명 센터로 이동
- 계정에 대해 활성화해 원하는 계정을 클릭해 원하는 곳으로 바로 연결
- 즉, 콘솔에 로그인 방법을 알 필요 없이 IAM 자격 증명 센터 포털에 로그인해 여러 콘솔에 액세스
- 여러개의 AWS 계정을 갖고 있다면 이 서비스 사용을 추천 한다.
동작 방식
- 그걸 다른 사용자 스토어와 통합해야 한다.
- 클라우드 또는 온프레미스에 있는 Active Directory 가능
- 또는 IAM 자격 증명 센터를 사용
빌트인 자격 증명 스토어에서 사용자나 그룹을 정의 - ID 센터를 AWS 조직이나 Windows EC2 인스턴스, 비즈니스 클라우드 애플리케이션, 사용자 정의 SAML2.0 지원 애플리케이션 등과 통합 한다.
- 그럼 이 모든 것에 한 번만 로그인해도 액세스 가능.
- 자격 증명 센터에서 권한 셋을 정의해 모두 액세스하지 않고 어떤 사용자가 무엇에 액세스할 수 있는지 정의 가능.
IAM 자격 증명 센터와 권한, 사용자, 그룹과의 연관
- 조직이 하나 있고 관리 계정에 IAM 자격 증명 센터를 설정한다.
- 두 개의 OU가 있고 개발 OU와 프로덕션 OU가 있고 각각의 계정이 있다.
- 회사에는 밥과 엘리스 두 명의 개발자가 있다.
Bob과 Alice에 대해 개발자 그룹을 만들자
- 밥과 엘리스가 개발 OU에 대해 전체 액세스 권한을 갖도록 하려한다.
- 따라서 권한 셋이라는 것을 만들어 거기에 관리자 액세스를 허용한다.
- 그리고 이 권한 셋을 특정 OU와 연결해야 한다.
즉, 개발 OU에 있는 사람과 연결하는 것이다.
- 그리고 이 권한 셋을 개발자 그룹에 할당한다.
그러면 밥과 엘리스는 전체 액세스를 허용하는 모든 개발 계정에서 역할을 맡을 수 있다.
- 마찬가지로 프로덕션 OU에 대해 읽기 전용 액세스라는 다른 권한 셋을 만들 수 있다.
- 그것과 연결하고 다시 권한을 개발자 그룹에 할당한다.
- 이런 식으로 사용자를 그룹, 권한 셋, IAM 자격 증명 센터의 특정 계정 할당에 연결할 수 있다.
세분화된 권한 및 할당(▲)
- 다중 계정 권한
- 이 서비스를 사용하면 조직에서 여러 계정에 대한 액세스를 관리할 수 있다.
- 또한 권한 셋을 사용해 AWS에서 사용자가 무엇에 액세스할 수 있는지 정의하기위해 사용자를 그룹에 할당하는 하나 이상의 IAM 정책을 정의
- 애플리케이션 할당
- 어떤 사용자 또는 그룹이 어떤 애플리케이션에 액세스할 수 있는지 정의
- 그러면 필요한 URL, 인증서, 메타데이터가 제공된다.
- 이 모든 것을 기본적으로 지원하고 이를 속성 기반 액세스 제어라 부른다.
- 속성 기반 액세스 제어(ABAC;Attribute-Based Access Control)
- IAM 자격 증명 센터 스토어에 저장된 사용자 속성을 기반으로 세분화된 권한을 갖게 되는 것.
태그 같은 걸 갖게 되는 것 - 이를 사용해 사용자를 비용 센터에 할당하거나, 주니어나 시니어와 같은 직합을 주거나, 로케일을 줘서 특정 리전에만 액세스하도록 할 수 있다.
- 사용 사례
- IAM 권한 셋을 한 번만 정의하고 기본 속성만 바꿔서 사용자 또는 그룹의 AWS 액세스만 수정하는 것.
이것은 고급 사용 사례이지만 IAM 자격 증명 센터를 사용해 활성화된다.
AWS 디렉토리 서비스
Microsoft Active Directory
- Microsoft AD는 AD 도메인 서비스를 사용하는 모든 윈도우 서버에 사용되는 S/W이다.
- 객체의 데이터베이스이고, 사용자 계정, 컴퓨터, 프린터, 파일 공유, 보안 그룹이 객체가 될 수 있다.
- 전체 Microsoft 생태계에서 관리되는 온프레미스의 모든 사용자는 Microsoft AD의 관리 대상이 된다.
- 중앙 집중식 보안 관리로 계정 생성, 권한 할당 등의 작업이 가능하다.
- 모든 객체는 트리로 구성되며 트리의 그룹을 포리스트라 한다.
- AD 전반적인 개념
- 도메인 컨트롤러에 계정을 생성한다
- 다른 모든 윈도우 머신은 동일한 네트워크에 있고, 도메인 컨트롤러에 연결될 것이다.
- 첫 번째 머신에서 도메인 컨트롤러 ID,PASS를 사용하면 도메인 컨트롤러는 로그인 정보가 있는지 컨트롤러를 확인한 다음 로그인을 허용한다.
- 모든 머신은 도메인 컨트롤러에 연결되어 있으므로 사용자는 어떤 단일 머신에서도 액세스할 수 있다.
AWS Directory Service
- AWS에 액티브 디렉터리를 생성하는 서비스(3가지 서비스)
- AWS 관리형 Microsoft AD
- AWS 자체 액티브 디렉토리를 생성하고 로컬에서 관리할 수 있고, 멀티팩터 인증을 지원한다.
- 독립 실행형 Active Directory로 사용자가 있는 온프레미스 AD와 신뢰 관계를 구축할 수 있다.
- AWS 관리형 AD가 온프레미스 AD와 상호 신뢰 관계를 구축하게 되는 것
- AWS 관리형 AD의 인증된 사용자가 AWS 관리형이 아닌 계정을 사용할 때 온프레미스 AD에서 계정을 검색할 수 있다.
- 반대로 온프레미스 AD 사용자가 AWS 계정을 사용해 온프레미스 AD에서 인증하려 할 때도 신뢰 관계에 의거해 AWS AD에서 검색할 수 있다.
- 즉, 온프레미스와 AWS 액티브 디렉토리 간에 사용자가 공유되는 것.
- AD 커넥터
- 디렉토리 게이트웨이(proxy)로 온프레미스 AD에 리다이렉트하고, MFA를 지원한다.
- 사용자는 온프레미스 AD에서만 관리된다.
- AD 커넥터는 프록시로 기능하기때문에 사용자가 AD 커넥터를 사용해 인증하려고 하면 온프레미스 AD에 요청을 프록시하고 찾아볼 뿐이다.
- 첫 번째 유형인 AWS 관리형 Microsoft AD에서는 AWS 관리형 AD와 온프레미스 AD 모두에 사용자가 있었는데 AD 커넥터는 이름처럼 연결하는 역할을 한다.
- 즉, 온프레미스 AD에 쿼리와 연결 요청을 프록시하므로 온프레미스 AD에서만 사용자를 관리할 수 있다.
- Simple AD
- AWS의 AD 호환 관리형 디렉토리
- Microsoft 디렉토리를 사용하지 않고, 온프레미스 AD와도 결합되지 않는다.
- 온프레미스 AD가 없으나 AWS 클라우드에 액티브 디렉토리가 필요한 경우 독립형인 Simple AD 서비스를 사용한다.
- 액티브 디렉토리를 사용해 윈도우를 실행할 EC2 인스턴스를 생성하고 이 윈도우 인스턴스는 네트워크용 도메인 컨트롤러와 결합되어 모든 로그인 정보와 자격 증명 등을 공유한다.
- 윈도우를 실행하는 EC2 인스턴스와 디렉터리를 가까이 위치시킬 수 있음.
- AWS 관리형 Microsoft AD
IAM Identity Center - 액티브 디렉토리 통합 방법
- Directory 서비스를 통해 AWS 관리형 AD 연결할 경우
- 통합이 즉시 가능함.
- IAM Identity Center를 AWS 관리형 Microsoft AD에 통합하고 연결하도록 설정하면 된다.
- 통합이 즉시 가능함.
- AD를 클라우드에서 관리하지 않고 온프레미스에 자체 관리형 디렉터리가 있는 경우
- AWS 관리형 Microsoft AD를 사용해 양방향 신뢰 관계를 구축
- 클라우드에 있는 AD에서 사용자를 관리하고 싶은 경우 사용
- Directory 서비스를 이용해 관리형 Microsoft AD를 생성하고 온프레미스에 있는 AD와 관리형 AD 간에 양방향 신뢰 관계를 구축
- 이후 IAM Identity Center에서 SSO으로 간단히 통합하면 된다.
- AWS 관리형 Microsoft AD를 사용해 양방향 신뢰 관계를 구축
- AD 커넥터를 활용하는 방법
- API 호출만 프록시 하고싶은 경우 사용(단, 지연 시간이 길어짐)
- AD 커넥터를 IAM Identity Center와 연결하는 역할을 한다.
- 연결 후에는 자동으로 모든 요청을 자체 디렉터리로 프록시한다.
- AD 커넥터를 활용하는 방법
AWS Control Tower
- 모범 사례를 기반으로 안전하고 규정을 준수하는 다중 계정 AWS 환경을 쉽게 설정하고 관리할 수 있음.
- 다중 계정을 생성하기 위해 Control Tower 서비스는 AWS Organization 서비스를 사용해 계정을 자동 생성한다.
- 장점
- 클릭 몇 번으로 환경을 자동으로 설정
- 원하는 모든 것을 미리 구성 가능
- 가드레일을 사용해 자동으로 지속적인 정책 관리를 할 수 있다.
- 정책 위반을 감지하고 자동으로 교정할 수 있다.
- 대화형 대시보드를 통해 모든 계정의 전반적인 규정 준수를 모니터링
AWS Control Tower - 가드레일
- AWS에서 다중 계정을 설정한다 가정하면 특정 항목에 관해 한 번에 모두 제한하거나 특정 유형의 규정 준수 사항을 모니터링하고자 한다.
이때 가드레일을 사용하면 Control Tower 환경 내의 모든 계정에 관한 거버넌스를 얻을 수 있다. - 유형(2 가지)
- 예방 가드레일
- 계정을 무언가로부터 보호하는 것으로 제한적이기 때문에 AWS Organization 서비스의 서비스 제한 정책인 SCP를 사용해 모든 계정에 적용한다.
- 예시
예방 가드레일을 생성해 모든 계정에서 리전을 제한하고 us-east-1과 eu-west-2의 리전에서만 작업해라 - 즉, Control Tower에서 Organization에 SCP를 사용하도록 하는 것
- 탐지(Detective) 가드레일
- 규정을 준수하지 않는 것을 탐지
- AWS Config 서비스를 사용한다.
- 예시
계정에서 태그가 지정되지 않은 리소스를 식별한다 하면 Control Tower로 탐지 가드레일을 설정하고 AWS Config를 사용하면 모든 멤버 계정에 Config가 배포되어 규칙과 태그가 지정되지 않은 리소스를 모니터링 하는데,
규정을 준수하지 않으면 SNS 주제를 트리거해 관리자로서 알림을 받거나 SNS 주제도 Lambda를 실행해 자동으로 문제를 교정하게 할 수 있다.
- 즉, 태그가 지정되지 않은 리소스에 태그를 추가하게 된다.
- 예방 가드레일
