woongs dogfoot

AWS Organizations

• AWS Organizations : AWS 계정 조직
  
  
  

• 특징

1. 하나의 관리계정, 다수의 기타계정으로 이루어짐
2. Organization내 member계정의 비용은 하나의 관리계정에서 지불
3. 비용할인은 member계정의 서비스 사용 총액을 기반으로 매겨짐
4. reserved instances, saving plan 등 Organization내 다른 계정들과 공유됨 -> 다른 계정에서 사용하지 않는 reserved instance가 있을 경우, 다른 계정이 사용 가능

• 장점

1. 다수의 VPC를 가진 단일 계정에 비해 보안이 좋음 -> 계정간 독립성이 좋음
2. 모든 계정의 CloudTrail log를 중앙 계정의 S3로 전송가능
3. 모든 CloudWatch logs를 중앙 계정으로 전송 가능
4. 관리 계정에서 모든 멤버 계정을 관리 가능
5. SCP (Service Control Policies) 정의 가능, OU or 계정에 적용되는 IAM 정책 -> 관리계정에는 적용되지 않음 -> IAM 권한은 default가 모든 권한을 허용하지 않음
6. SCP는 차단목록과 허용목록 두 가지 전략이 있음
   
   
   

• SCP Example

IAM Conditions

• IAM Conditions : 특정 resource에 대한 IAM Policy의 조건
  
  
  

1. aws:SourceIp : API호출에서 Client ID를 제한하는 데 사용
2. aws:RequestedRegion : API호출에 대한 region 제한
3. ec2:ResourceTag : EC2 인스턴스에 한해 특정 tag를 가지고 있으면 명시되어 있는 action 허용/제한
4. aws:PrincipalTag : 해당 tag의 사용자는 명시되어 있는 action 허용/제한
5. aws:MultiFactorAuthPresent : MFA 여부에 따라 명시되어 있는 action 허용/제한
6. aws:PrincipalOrgID : AWS Organization 멤버 계정에만 리소스정책이 적용되도록 제한 (organization ID 명시 필요)

• IAM for S3 (bucket policy)

1. bucket 수준의 policy는 bucket을 특정해야 함 -> Resource에 특정 s3 arn(Amazon Resource Number)을 명시하면 됨 (ex. arn:aws:s3:::test -> test bucket)
2. 객체 수준의 policy는 object를 특정해야 함 -> ex. arn:aws:s3:::test/* -> test bucket내의 모든 객체
3. action example : s3:GetObject, s3:PutObject, s3:DeleteObject
   
   
   

IAM Roles vs Resource Based Policies

• Resource Based Policies을 지원하는 서비스 : S3, SNS topic, SQS queue, Lambda, CloudWatch logs, API Gateway etc...
  
  
  

• 서로 다른 계정간 접근일 경우

1. IAM Role을 이용한 접근 : 기존 권한을 모두 버리고 IAM Role을 통해 할당받은 권한만 활용 (기존권한 활용x)
2. S3 Bucket Policy를 통한 접근 (Resource Based Policies) : IAM Role을 할당받는 것이 아니기 때문에 기존 권한을 버리지 않음

• Amazon EventBridge를 사용할 때

1. target이 Resource Based Policies을 지원하는 서비스일 경우, RBP 설정 필요
2. target이 Resource Based Policies을 지원하지 않는 서비스일 경우, EventBridge에 IAM Role 설정 필요

IAM Permission Boundaries

• IAM Permission Boundaries : IAM의 최대 권한을 정의하는 기능, 해당 기능을 특정 IAM User에 할당하게되면, 할당된 권한 Boundary내의 권한만 얻을 수 있음 (Boundary 외의 IAM Role권한을 할당받을 경우, 권한 활용 불가)

• 특징

1. user/role에 한함 (group은 지원 안함)
   
   
   

• AWS Organization 권한과 중첩이 된다면?

1. Identity-based policy : user나 group에 할당되는 Identity기반 권한
2. Permission Boundary : user나 role에 적용
3. Organization SCP : 계정 내 모든 IAM User에 적용

-> Effective permission만 행사 가능

• 정책 평가 과정

1. Deny가 명시되어 있으면 Deny 우선
2. 명시적 Deny가 없어도 명시적 Allow 역시 없으면 실행 불가

AWS Control Tower

• AWS Control Tower : 규정을 준수하는 다중 계정의 AWS 환경을 손쉽게 설정하고 관리할 수 있음

• AWS Organization을 통해 계정을 자동 생성

• 정책 위반 감지 및 자동 교정 가능

• guardrail을 활용하여 지속적인 정책관리 가능

• 모든 계정의 규정 준수여부를 대시보드를 통해 모니터링 가능
  
  
  

• Guardrail : 특정 항목 일괄 제한 및 특정 유형의 규정 준수여부 모니터링, Control Tower에 대한 모든 계정의 거버넌스 제공

1. Prevent Guardrail : Control Tower에서 Organization에 SCP를 사용하도록 강제
2. Detective Guardrail : AWS Config 서비스를 활용하여 규정을 준수하지 않는 것을 탐지 (AWS Config 규정준수 여부 탐지 -> Guardrail trigger -> SNS...)

• IAM : Identity and Access Management, Global
• IAM 계정은 root 사용자이고, 계정을 만들 때에만 사용해야 함.
• root 계정으로 동일 관리자 권한을 가진 사용자를 생성할 수 있음 => IAM 사용자
• 사용자를 그룹으로 묶을 수도 있음
• 그룹 내에 그룹이 배치될 수 없음
• 사용자가 여러 그룹에 속할 수 있음
  
  
  

• Json 문서 형태의 정책을 그룹이나 사용자에 적용할 수 있음 (어떤 작업, 어떤 서비스에 대한 권한을 설정)

• 최소 권한의 원칙
  
  
  

• 인라인 정책 : 그룹이 아닌 사용자에게 직접 부여하는 권한

• 특정 사용자가 두 그룹 이상에 속해있을 경우, 두 그룹의 권한을 모두 상속 받음
  
  
  

• aws console 내 사용자 -> 권한 탭에서 그룹 또는 인라인정책을 통해 부여받은 권한목록 확인 가능

• 특정 권한을 선택하면 세부 권한 확인 가능, JSON 버튼을 누르면 위 사진처럼 JSON 포맷의 세부 권한정보를 확인할 수 있음

• aws console 내 사용자 -> 그룹 탭에서 속해있는 그룹을 확인할 수 있고, 추가하거나 제거할 수도 있음.
  
  
  

• 정책 구조

1. Version : 정책의 버전 (날짜 형식)
2. id : 식별자 (Optional)
3. Statement : 실질적 정책 내용
   1. Sid : 정책 내용의 식별자 (Optional)
   2. Effect : 특정 API에 대한 접근을 허용할지 결정 (Allow/Deny)
   3. Principal : 특정 정책이 적용될 사용자, 계정, role로 구성
   4. Action : Effect에 의해 허용되거나 거부되는 API 호출 목록
   5. Resource : action이 적용될 resource 목록
   6. Condition : Statement가 언제 적용될지에 대한 조건 (Optional)
      
      
      

• 그룹과 사용자들의 정보를 보호하는 방법

1. 비밀번호 정책 정의 -> 복잡할 수록 보안이 강해짐 (ex. 비밀번호 패턴 설정, 만료기간, 변경요구, 이전 비밀번호 변경으로 제한 등)

2. (시험) 다요소인증 MFA (Multi-Factor Authentication) : 비밀번호와 함께 사용하는 보안장치 (OTP 같은거라고 보면 됨)

   • 루트 계정, IAM계정은 반드시 보호 필요,
     ex. 로그인 시, 비밀번호 입력과 함께 MFA 토큰필요
   • MFA 옵션

   1. 가상 MFA 장치 (google auchentication), 여러개 토큰 지원 => 하나의 장치로 여러 사용자 이용 가능

      

   2. U2F 보안 키 : 물리적 키 (likes USB), 하나의 물리적 장치에서 관리하는 보안 키를 활용, 하나의 키로 여러 루트 계정과 IAM 사용자를 지원

      

   3. 하드웨어 키 팝 : U2F 보안키와 동일

      

   4. 미국 정부 클라우드인 AWS GovCloud 활용 시 필요

      

• AWS에 접근하는 방법

1. Console : password + MFA로 보호됨
2. AWS CLI : 터미널에서 접근 access key로 보호됨
3. AWS SDK : 애플리케이션 코드에서 접근, access key로 보호됨
   • Example : AWS CLI는 Python용 AWS SDK를 활용해 구축함.
     
     
     

• AWS CLI : AWS public API에 직접 접근 가능, 명령어 조합의 스크립트를 작성하여 자동화도 가능
  

  

• AWS CLI는 오픈소스로 GitHub에서 확인 가능
  
  
  

• access key 생성 : AWS Console에서 생성 (암호 형태)

1. Access Key ID ~= username (공유x)
2. Secret Access Key ~= password (공유x)
   
   
   

• AWS CLI 실습 in window

1. aws CLI install windows 검색
2. MSI 설치 프록그램을 통한 window에서의 AWS CLI 설치
3. 프롬프트창에서 aws CLI 설치되었는지 확인 : aws --version 명령어
   
   
   

• AWS CLI 실습 in mac OS

1. install aws cli mac 검색
2. pkg 설치 프로그램을 통한 mac에서의 AWS CLI 설치
3. 터미널에서 aws CLI 설치되었는지 확인 : aws --version 명령어
   
   
   

• AWS CLI 사용

1. Access key는 사용자 -> Security Credentials에서 생성
2. 터미널에서 aws configure 명령어를 입력하여 access key 입력창 출력
3. aws 명령어를 입력하면 명령어에 맞는 응답을 JSON형태로 출력해줌 (ex. aws iam list-user : 내 계정내 모든 사용자 출력)
4. aws console을 통해 부여받은 키에 해당하는 계정에 특정 권한을 제거할 경우, aws CLI에서도 동일하게 적용됨.
   
   
   

• Cloud Shell : AWS에서 무료로 제공하는 터미널 서비스, 터미널 대신 AWS에 명령을 내릴 수 있음 (console 화면 우측 상단에 위치, 사용가능 Region 한정)

• Cloud Shell은 공용 저장소 사용 -> 껐다 켜도 이전 터미널에서 생성한 파일이 남아있음 -> 로컬로 다운로드 하거나 로컬에서 업로드할 수도 있음

• 터미널 서식변경도 가능

• 멀티 터미널도 가능
  
  
  

• IAM ROLE : AWS 인스턴스에 의해 사용되도록 만들어진 Role (ex. 특정 EC2 서비스가 타 서비스를 이용하기 위한 권한 집합, EC2 Instance Roles)
  
  
  

• IAM Security Tools (기능이라 보면 될 듯)

1. IAM Credentials Report (IAM account-level) : 특정 IAM 계정(ex. djeon)에 대한 사용자 목록과 그들의 자격증명(id, pw) 상태를 확인
2. IAM Access Advisor (user-level) : 사용자(ex. aws-djeon-v1)에 부여된 권한과 마지막 접근 시간 확인 (권한 사용여부 확인을 통한 최소권한 원칙 준수)